Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Alexis Ballier]

On Sat, 09 Feb 2013 15:12:15 +0100
Luca Barbato <lu_zero@g.o> wrote:

> On 08/02/13 22:46, Alexis Ballier wrote:
> > On Fri, 08 Feb 2013 22:41:04 +0100
> > Maciej Mrozowski <reavertm@×××××.com> wrote:
> >
> >> On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote:
> >>
> >>> Tomáš Chvátal wrote:
> >>>> we as gentoo will provide both while preffered default will be
> >>>> what major distros use.
> >>>
> >>> What kind of careless mainstream attitude is that? Really?
> >>
> >> Quite the opposite, decision to use implementation A over B was
> >> taken with utmost care for user in mind.
> >
> > Not really. I was promised a discussion that hasn't happened yet.
>
> I'm available for discussion anytime, I got a little busy in the past
> days and I will busy the next 3 days, but I should be available today
> evening or now.

Sorry, I was away this week end...

> I stated already what I think about the whole discussion in a blog
> post.

I'm not fond of discussions via blog posts and do not think it is
the right media. I wrote one only to make it clear the decision was
not anything near a general consensus, when Tomás made it sound like it
was.

> To summarize it my take is quite simple, Libav leads the way regarding
> the main API,

This is only because libav people do not care at all about what FFmpeg
defines, while FFmpeg seems to care more about its consumers and users
by trying to provide a compatible ABI and API. Moreover, this is not
true at all when it comes to the parts where supporting both forks is
painful: libavfilter and audio resampling. It is pretty clear that the
audio resampling wheel was reinvented on the libav part, with a
different library name and in 95% of its use cases going from ffmpeg's
audio resampling to libav's is mainly a matter of 'sed s/swr/avr/'.
Some parts of libavfilter also appeared later in libav, sometimes with
a slightly different API, making it really awful to support both forks
in applications.
(I'm still looking forward a patch for xbmc and upstreamed patches for 
mplayer btw)

> it offers a more compact surface for attacks if you are
> really concerned about security and usually it is a little more
> compact

If you mean that ffmpeg is libav + ffmpeg additions, then yes.
However, if you are concerned by a more compact surface, then libav is
not the right answer: you can very well disable selected codecs,
(de)muxers, etc at build time. I even started to work on reflecting this
into an ebuild some years ago before reaching the conclusion that it
would be confusing for little to no gain. This can of course be done if
there is some demand, but so far I have not seen any.

It is funny to see how libav ignores completely ffmpeg even for
bugfixes, I stumbled over this recently and it sounded familiar:
http://git.libav.org/?p=libav.git;a=commitdiff;h=89f11f498b9c15bc71494a11a7ec560f4adf630d
vs
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1af91978dbab35ba9fdede187577c00d643ae33b
now, you can look at the dates, there's a one year lag in libav for
reinventing the same bugfix. This is for a format almost nobody uses,
but in any case I do not consider this attitude sane.

> and a bit more tested over a wider range of architectures.

If you are talking about fate, then I cannot comment. fate started
before the split, so I assume the owners of said test machines took
them within their respective fork.

> I'm not for removing ffmpeg overnight since there are features that
> might be of use and I'm not so hypocrite to value diversity only when
> it is in favor of my interests.

Nobody talked about removing anything :)

> That said as long the two project are compatible having one or another
> as default is just a matter of making our life easier.

I fully agree there, but you should be careful with who you include in
'our'. In the case of a default then it is clearly 'the users'. Now,
considering there are a couple (very few) of packages that do not
compile with libav, do you consider having it as default a good idea?
Those packages can very well be fixed, but if patches do not go
upstream, this is not going to work in the long term. Also, the only
reason why I have not pinned those packages to depend only on
media-video/ffmpeg is because libav is not the default (not entirely
true btw, see later), meaning those that use libav are those that are
willing to help and know what they are doing. If people are to get
libav by default and then hit compile failures to be told to use
ffmpeg, then it is QA 101 that these packages should be depending on
media-video/ffmpeg.

[...]
> Few large projects such as VLC and Gstreamer switched to Libav as
> their default.

... and chrome, mplayer, xbmc use ffmpeg :=)
also as I said in another email, I have yet to see a libav based vlc
release.

> Since Libav is the no-frills variant, notwithstanding the interesting
> campaign of "we have more security11ein!" less stuff should break
> since it is usually more tested and once we gather the samples
> triggering a crash usually we do not stop preventing that single
> crash but the whole class of possible defect (see my work on mov as
> an example).

Probably true, but I still consider a quick fix disabling the
vulnerability to be released quickly is a good thing. A complete
rework and fix can be done later, but users should not be exposed for
the sake of being perfect. That is what happens with FFmpeg merging from
libav. It is, however, sad and annoying to see it done like that
(claiming having fixed it and then having a better fix coming from
those you first claimed you were better).

[...]
> I hope somebody not Libav nor FFmpeg committer could come up with a
> pros-cons list.

By the way, I do not know why you still consider me a FFmpeg committer,
of course I can git clone and commit but someone has to push for me.
You should probably search me in FFmpeg's git log, the only things I
have done is the usual downstream patches going upstream and writing,
years before the split, a qtrle encoder I needed for some course I was
teaching.
Also, I never understood why you consider Tomás to be neutral: He has
been playing with libav almost from day 1, adding the virtual/ffmpeg
mess (which was solved since then but it was a real mess wrt useflags),
made mplayer use libav as its internal version in our ebuilds despite
upstream using ffmpeg (the point of the internal version is to be the
same as upstream, so I had to finally do the only sane thing by making
it use external ffmpeg, and then nobody cared about porting it to libav
until very recently), introduced the libpostproc mess and subtly used
the need to change some packages' deps to put libav as the leftmost
choice (ie default), insulted me because I did the work of porting a
package to recent ffmpeg versions while not understanding this leaves
only little work to also support recent libav versions...

These two posts are interesting for anyone wanting to understand the
situation also (1st more from ffmpeg side and 2nd more from libav's):
http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
http://codecs.multimedia.cx/?p=370

Alexis.