On Sat, 09 Feb 2013 15:12:15 +0100 Luca Barbato <lu_z...@gentoo.org> wrote:
> On 08/02/13 22:46, Alexis Ballier wrote: > > On Fri, 08 Feb 2013 22:41:04 +0100 > > Maciej Mrozowski <reave...@gmail.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.
