On Wed, 16 Jan 2013 21:39:04 +0100 Luca Barbato <lu_z...@gentoo.org> 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.
