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 Wed, 16 Jan 2013 21:39:04 +0100
Luca Barbato <lu_zero@g.o> wrote:

> On 16/01/13 21:09, Alexis Ballier wrote:
> > More seriously: Why ? Who decided this ?
>
> I never pushed my weight over it before since as you are involved in
> FFmpeg directly, I am involved in Libav directly.

I don't know what you mean by involved directly, but ffmpeg happens to
be what I use and care about, hence I have a couple of commits there
but their number is quite ridiculous in comparison. [Actually, I should
be honored that you compare my involvement with yours :)]

> Thus anything I say on this topic has a clear bias. Same goes for you.

... but I admit I have some bias, however, I'm rather a consumer than a
developer when it comes to ffmpeg and believe we need to think as
consumers as a downstream distro.

> Tomas is not related to libav beside one of his core project using it
> by transition, so I would expect him to be less biased than us.
>
> > Let's be realistic, both upstreams claim they're better than the
> > other in one way or another, and let's think like serious
> > downstreams, not like upstream playground.
>
> VLC uses it since ffmpeg doesn't work with rtmp properly last time
> they checked and other interesting situations.

interesting, did they report it? OTOH, they switched _after_ the 2.0.5
release which happens to be the latest one. Since vlc is probably the
ffmpeg/libav interface the most popular in the world (due to their
windows and mac builds), I'd like to see an actual release with it and
see if there is any regression before claiming they use libav.

> gst-ffmpeg/gst-libav works only with libav as per upstream desire
> (thus the rename)

you mean use libav internally? because 'per upstream desire'
gst-ffmpeg or gst-libav always only worked with the internal libs :)
it also appears to build and work fine with ffmpeg-0.10

> ubuntu and debian just use Libav.

Speaking about bias, the maintainer happens to be part of libav core
developers and was even part of what is known as the 'ffmpeg coup' :)

> > As a downstream, I can see plenty of reasons against, but none in
> > favor of this change:
> > - There are still a couple of non-trivial packages that need to be
> >   fixed to work with libav while I don't know any that works with
> > libav but not ffmpeg.
>
> See above for the other way round.

None of what you cited is a problem for a downstream distribution,
except maybe vlc+rtmp which should be fixed regardless.
xbmc and mplayer did not build last time I tried. xbmc will be a pain
because it uses some libavfilter features not in libav.

> > - All (but the one discovered in Nov. 2012) of the security issues
> >   fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May
> > 2012 (!!) for ffmpeg according to the website... 8 months before...
>
> The security game is fun. Given the number of "additional features"
> the surface impact is bigger in FFmpeg and currently all but one of
> the bugs claimed as security issues originate from the same guy he
> claim to fix them (sometimes the fix doesn't address the underlying
> issue but just _that_ specific sample).

I don't want to verify this and will trust you there, but I still
don't consider 8 months to be a correct delay for handling a published
vulnerability, whatever its origin may be.

> I'd rather avoid having another mud sliding contest.
>
> I stopped caring about FFmpeg since somebody gave a sample of his
> humor wishing my death.

This is getting personal :) I'm sure the fork didn't happen because
some day some devs woke up angry because they didn't have had their
coffee. However, I'm also sure the fork is a pain for downstream
distros and a lot of upstreams.

Alexis.