libav_0.6.2-1_i386.changes is NEW

[Reinhard Tartler]

On Fri, Mar 25, 2011 at 10:50:02 (CET), fabian at greffrath.com wrote:

> Honestly, I still don't get it.
>
> Is libav merging from ffmpeg or the other way round? I have just read that
> ffmpeg has merged ffmpeg-mt, but could not find such an announcement from
> libav yet. If the two projects merge back and forth anyway, why is there a
> need for two separate code bases?

Yeah, I agree that this is terribly confusing and Libav should finally
get the planned "About Libav" clarification out.

A (arguably large) number of FFmpeg developers felt very unhappy about
the way how FFmpeg is driven and managed in general and the project
leader in particular. Many attempts to resolve and reconcile the issues
internally have been attempted but unfortunately, each of them have
failed. Therefore, these developer had no other option than properly
forking, something that many have (both FFmpeg developers and outsiders
such as users, etc.) requested.

FFmpeg currently has no single release manager. I'm in very close
contact with Libav developers and will continue to drive releases
there. For Debian, I think this constitutes an invaluable asset, that's
why I have uploaded Libav.

> And does the "original" ffmpeg project now use the ffmpeg.org name space
> that has been initially set up by the fork now called libav?

Exactly. The DNS has moved, and the server (natsuki.mplayerhq.hu) that
has served ffmpeg.org before is now hosting libav.org. Most of the
technical infrastructure, such as mailing list, bug tracker, fate.libav.org,
etc. remains on natsuki to serve libav.org.

What we see now is that FFmpeg is acting IMO in a pretty panic driven
way. With no release manager, no release roadmap or any kind of vision,
many very confusing merges in git (from ffmpeg-mt and libav.org) and
lots of reverts, I really think Debian is much better off with Libav.

Regarding the ffmpeg-mt: This is yet another pretty political move (and
one that I personally find quite offensive, BTW). Fact is that ffmpeg
supported multi threading for quite some time, what's new is a)
infrastructure for slice based multi threading and b) porting of codecs
to use that infrastructure. Libav has merged most of the ffmpeg-mt
branch long before FFmpeg (way before Libav.org went online) but failed
to make a public fuzz about it. What is missing are multi threaded h264,
h263, etc. codecs, which is currently worked on (and I marked that
release blocker for 0.7). They haven't been merged yet because they
break the regression tests. Michael vetoed ffmpeg-mt for years because
of that. Now, he has merged it without any public coordination.

>  - Fabian
>
> PS: And I already have a *bit* of insight. What do you think how puzzled
> other users/packagers/potential contributors are?!

As indicated above, there is a clarification from the Libav side pending
that will hopefully clear up many things.

The situation isn't that bad as it seems. There is a considerable amount
of code exchange between the two projects (just check the commit mailing
lists), and what's most important for us downstreams: The competition
that has arisen now has speeded up the development of user visible
features, such as the merge of ffmpeg-mt, a lot. Which I think is great
news!

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4