On 11/02/13 03:01, Alexis Ballier wrote: > Sorry, I was away this week end...
Not a problem, I should be reachable anytime today. > 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. The reasons about that could be multiple, the facts are those. If you want you application to run in both you pick the Libav 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/'. Not really, the resample library idea was brewing for long even pre-fork, it got released first on FFmpeg because there is this bulimic tendency to add more features in order to be compelling in FFmpeg. I said already what happened when I started to develop the pulse capture and the generic segmenter in my github as another example of stuff developed by unrelated people and curiously landing before deemed ready by the author in ffmpeg git. (prores could be considered yet another funny example). > 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. libavfilter is deemed still not ready for general consumption in Libav and just the set of calls that won't change (hopefully) in the future are provided. Meanwhile we are trying to make the whole buffer management less copy-happy and a little more rational. (not sure if you tried to use libavfilter but it is a _bit_ hard to use if compared to vlc filter layer and such) > (I'm still looking forward a patch for xbmc and upstreamed patches for > mplayer btw) I might spend a little time. >> 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. The ebuild supports extra parameters for that specific purpose. > 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. Nobody is perfect and not everybody has the time to track another project tree every day. >> 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. That speaks a *bit* about the general support maybe? > 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? I have no opinion, I stayed out of the discussion and decision about that before because I know I have a bias. I let other people decide. > 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. You can, if you really want, offset ffmpeg so it doesn't clash with Libav. > ... and chrome, mplayer, xbmc use ffmpeg :=) Chrome uses its own fork, reverting some changes form FFmpeg and picking what they deem useful. mplayer changes ffmpeg when they need something as they please xbmc used the new&improved libavfilter API to access swscale, the restricted api seems to work just fine. > Probably true, but I still consider a quick fix disabling the > vulnerability to be released quickly is a good thing. No, it is in general a really stupid idea. You are basically telling the interested attackers where the problem is. Then the attacker does +1 and you have your new, freshly installed application compromised. It is the _worst_ possible service you could do. Think about a random rpc system with 4 calls that are similar and go down the same codepaths, some fuzzer discovers that sending a message with a certain shape let you crash the application. The fix pushed and published with much fanfare is "if $shape then error" for that specific rpc call. Pity that that similar shapes would crash the other rpc calls, thus anybody with interest in crashing the application have a good example on how to do that. Unrelated to the discussion please do not do that in any project you contribute. It is that _bad_ > 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. I thought you had the commit since svn time, I don't recall if I suggested it myself or other did. > Also, I never understood why you consider Tomás to be neutral I can't say about him, he never sent patches to us and he volunteer to do the virtual when I said that I'd rather have somebody else not related to the project. > 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 First one from one of the main ffmpeg committers nowadays the second from the main codec reverse engineer. lu
