<p dir="ltr"><br>
On May 15, 2015 4:56 PM, "Andreas Cadhalpun" <<a href="mailto:andreas.cadhalpun@googlemail.com">andreas.cadhalpun@googlemail.com</a>> wrote:<br>
><br>
> Hi Reinhard,<br>
><br>
> thanks for explaining your point of view here.<br>
><br>
> On 15.05.2015 09:23, Reinhard Tartler wrote:<br>
> > Thanks for this insightful post, Dmitry,<br>
> ><br>
> > On Mon, May 11, 2015 at 5:44 AM, Dmitry Smirnov <<a href="mailto:onlyjob@debian.org">onlyjob@debian.org</a> <mailto:<a href="mailto:onlyjob@debian.org">onlyjob@debian.org</a>>> wrote:<br>
> >> On Sat, 9 May 2015 16:00:49 Andreas Cadhalpun wrote:<br>
> >>> What would you count as very compelling reasons if more features, less bugs<br>
     > >>> and better security support are not sufficient?<br>
> >><br>
> >> More features is not necessary means less maintenance burden;<br>
> >> Less bugs is not always means better software (it is a matter of how upstream<br>
> >> manages bugs);<br>
> >> Quality of security support is something that remains to be seen.<br>
> ><br>
> > I think security is not a decisive topic where either project cannot<br>
> > clearly claim of having a clearly better handle.<br>
><br>
> I disagree: FFmpeg is clearly better at fixing security issues.<br>
> To take a random example, an out of bounds read in the bink decoder was fixed<br>
> in FFmpeg three years ago [1], while Libav git master is still vulnerable<br>
> today.<br>
><br>
> One can find more such examples, but I have better things to do with my time.</p>
<p dir="ltr">I think this sea0¨˜j67<br>
><br>
> > These days, FFmpeg for<br>
> > sure asks for most (if not all) CVE numbers recently assigned, and claims<br>
> > to provide patches for them.<br>
><br>
> FFmpeg not only claims to provide patches, but actually does provide them:<br>
> most CVEs link to the corresponding patch.<br>
><br>
> > What is less visible is what happens behind the scenes:<br>
> ><br>
> > Most of these issues originate from Google Guys that work on security and<br>
> > conduct fuzzing tests on libavcodec/libavformat. Their main target is of<br>
> > course their own libavcodec/libavformat fork that they ship in Chrome, but<br>
><br>
> As far as I'm aware they use a git snapshot of FFmpeg that they update<br>
> from time to time. They only change the build process to produce one single<br>
> libffmpegsumo library instead of libavcodec/libavformat/libavutil.<br>
><br>
> > they (of course) also share their samples with both Michael (FFmpeg) and<br>
> > Luca/Anton (Libav). Michael seems to have much more capacity and time, and<br>
> > thus is usually faster with pushing patches for such crashers.<br>
><br>
> Yes, Michael does an awesome job at fixing those [2].<br>
><br>
> > Libav takes<br>
> > the time to investigate, reproduce and understand those patches.<br>
><br>
> That's a commendable idea, but if the result is that these patches<br>
> don't get applied in a reasonable time frame, it's rather bad.<br>
><br>
> > Unfortunately, in the majority of cases, this is not trivial at all, often<br>
> > because of terse (or even wrong) commit messages, or the fact that there<br>
> > are better places to fix a particular issue in the code.<br>
><br>
> In that case it would probably help to ask the author of the patch.<br>
> Did the Libav developers do that?<br>
><br>
> > "Better" usually<br>
> > means that more than a single instance of the issue is fixed.<br>
><br>
> Can you give examples for this?<br>
><br>
> > Also, given that Libav supports significantly less codecs and formats (and<br>
> > in some cases specific variants or features of codecs), many security<br>
> > issues simply don't apply.<br>
><br>
> While it's true that some security issues only affect code not present in<br>
> Libav, the majority of issues affect both projects (until they are fixed in<br>
> FFmpeg).<br>
> Much of the additional code in FFmpeg poses nearly no security problem.<br>
> For example, even if there was a potentially security relevant bug in one<br>
> of the more than 100 additional filters in FFmpeg, it would be very hard to<br>
> exploit, since the filters generally have to be invoked manually.<br>
> Only decoders/demuxers can be easily triggered automatically,<br>
> e.g. by visiting a web site or opening a folder with images, for which<br>
> thumbnails are created.<br>
> Additionally it would be much easier to disable some rarely used features<br>
> in Debian's FFmpeg than to enable desired features in Debian's Libav,<br>
> when they are not present upstream.<br>
><br>
> > Libav could for sure do a much better job here by releasing faster. In the<br>
> > past, I looked at doing new point releases about every 2-3 months, but for<br>
> > family reasons, I wasn't able to keep that pace. Release frequency is<br>
> > clearly something that needs improvement. As far as for the release<br>
> > content, I am not aware of critical fixes being missed, so quality wise I<br>
> > think we are good.<br>
><br>
> You are wrong about the quality. Have a look at the bink example I gave above.<br>
><br>
> >> I have a feeling that Debian already became life support for libav.<br>
> >> Ever since Debian chosen libav, ffmpeg remained alive and apparently doing<br>
> >> well without our help. I'm not too sure if libav would be able to stay alive<br>
> >> without Debian.<br>
> ><br>
> > That's an interesting take on the matter. I don't think it is accurate; for<br>
> > instance OpenEmbedded or Gentoo also ship Libav (in favor of FFmpeg), so<br>
> > Debian&Ubuntu are clearly not alone.<br>
><br>
> Interestingly Gentoo recently switched to FFmpeg by default [3] after conducting<br>
> a survey [4]. About 300 people participated in that survey and the outcome<br>
> was rather clear:<br>
> 62%    [ 189 ]    "I prefer ffmpeg, and it should be the default."<br>
>  4%     [ 15 ]    "I prefer libav, and it should be the default."<br>
><br>
> > It is true that Libav owes the largest<br>
> > portion of its userbase to Debian&Ubuntu, however even if Debian would stop<br>
> > shipping Libav, then I doubt that this would threat Libav development in<br>
> > any way.<br>
><br>
> I'm not going to speculate about this.<br>
><br>
> >> From maintenance prospective libav seems to be a liability. We have to carry<br>
> >> patches for packages where upstreams are not too concerned about supporting<br>
> >> libav.<br>
> ><br>
> > This statement is a bit surprising to me.<br>
><br>
> Have you looked at the xbmc-libav-hacks [5]?<br>
> I can understand that they dropped them when releasing Kodi.<br>
><br>
> > At the time Debian started to<br>
> > ship Libav, there was absolutely *no* difference to FFmpeg. Since that,<br>
> > many things have changed, and the two code-bases have diverged. While<br>
> > FFmpeg started to merge as much functionality as possible, Libav focused on<br>
> > maintainability, cleaned and straightened-up APIs and removed fringe codecs<br>
> > and formats.<br>
><br>
> You forgot to mention that FFmpeg also fixed many bugs in the existing code<br>
> base and most of those fixes didn't make it to Libav.<br>
><br>
> >> Also in the light of past libav transitions and deprecations that required<br>
> >> multiple changes in Debian and upstream I know no upstream who is happy to<br>
> >> support libav.<br>
> ><br>
> > In practice, maintainability means something different for an upstream<br>
> > project and a distribution package. While upstream developers extend, fix<br>
> > and refactor the code-base,as package maintainers we make sure that<br>
> > the libavcodec package works fine with all applications that make use of it.<br>
> ><br>
> > To be totally blunt: The libavcodec/libavformat API is horrible. This is<br>
> > partly caused because of the aim to have a single library that covers every<br>
> > thinkable container and codec flavor using a common API. Libav has<br>
> > identified the development process as the culprit, where developers<br>
> > submit unfinished and unreviewed work to the main codebase, which is then<br>
> > used by applications and can basically never be fixed.<br>
> ><br>
> > In an attempt to provide applications a better interface to<br>
> > libavcodec/libavformat, Libav has in the past aggressively devised new<br>
> > and deprecated old APIs for maintenance reasons, i.e., helping the<br>
> > maintenance of the libav codebase.<br>
> > For Debian with a large two digit number of reverse dependencies, this<br>
> > caused a lot of fall-out that needed to be fixed. Libav developers were<br>
> > instrumental with providing patches to make them build again. FFmpeg tries<br>
> > hard to keep old APIs, which for sure lowers the effort for Linux<br>
> > distributions, but is it really better to keep applications that use<br>
> > obsolete and broken APIs? I'm not sure. In the long run, having<br>
> > applications use less horrible APIs is for sure a good thing.<br>
><br>
> FFmpeg merged those new APIs, while sometimes retaining the old APIs<br>
> longer to give applications more time to adapt.<br>
> When not many applications using the old APIs remain, they are dropped.<br>
><br>
> > I think the debate on the development methodology is the biggest<br>
> > disagreement between the two projects: FFmpeg insists on keeping its<br>
> > development velocity and allowing developers to "get work done",<br>
> > compromising on maintainability and common understanding of the code base<br>
> > in favor of more features.<br>
><br>
> I don't think getting work done is bad, because if work (like bug fixes)<br>
> doesn't get done, it is worse for maintainability.<br>
><br>
> > Libav on the other hand rather focuses on clean<br>
> > implementation and let's say better designed APIs.<br>
><br>
> Let's say Libav focuses more on cosmetics like consistent indentation,<br>
> use of spaces around brackets, a linear commit history and such.<br>
><br>
> > This requires more work,<br>
> > which in effect significantly lowers the development velocity. For a system<br>
> > integration job on the scale of Debian, less velocity seems more appealing<br>
> > to me.<br>
><br>
> Less velocity in fixing (security) issues seems everything but appealing.<br>
><br>
> > I'm having a very hard time to find an answer to the question which project<br>
> > is better for Debian. One way of looking at it is which causes less effort<br>
> > for the package maintainers. Andreas' and Dmity's mails make it sound that<br>
> > Debian could save a lot of effort by switching to FFmpeg. I'm honestly not<br>
> > sure if that is true. For instance, chromium upstream does not support<br>
> > linking against a system libavcodec library. Andreas had to provide a<br>
> > pretty invasive patch in #763632 for this, and I doubt that chromium<br>
> > upstream is interested in merging it.<br>
><br>
> The patch [6] is not invasive. The largest part is splitting a list of FFmpeg<br>
> functions used by chromium in three lists for functions from libavcodec,<br>
> libavformat and libavutil. (Chromium builds those into only one library,<br>
> libffmpegsumo.) Other than that it's about two dozen changed lines in<br>
> chromium upstream code to adapt to using three instead of one library<br>
> and to remove configuration #defines incompatible with the FFmpeg libraries<br>
> in Debian.<br>
> The reason for this is that chromium upstream basically contains support<br>
> for building against system FFmpeg libraries, it seems just rather unmaintained<br>
> and thus quite broken.<br>
><br>
> > My biggest concern with the list that Andreas provided in<br>
> > <a href="http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/043980.html">http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/043980.html</a><br>
> > is that the different upstream require specific upstream versions of<br>
> > FFmpeg, and will break with other versions, which was pretty much the state<br>
> > 2009-2010 when I more or less took over of the package: Many upstream just<br>
> > bundled some internal copy of libavcodec that they have developed against<br>
> > and were updated with a very inconsistent pace. I'm happy to see that<br>
> > FFmpeg finally no longer discourages the use of release tarballs in favor<br>
> > for "svn trunk" or nowadays "git master" on the download page.<br>
><br>
> I'm only aware of two projects that use sufficiently outdated FFmpeg versions<br>
> that they probably won't work with current FFmpeg: Avidemux and MythTV [7].<br>
> Neither of those are in Debian, precisely due to this fact.<br>
><br>
> > Nevertheless, the release frequency is just insanely fast,<br>
><br>
> It is about four major releases per year. There's nothing insane about that.<br>
> Libav now tries to make two major releases per year, because users requested<br>
> more frequent releases [8].<br>
><br>
> > and long-term<br>
> > support is practically non-existent: the oldest release branch was cut in<br>
> > 2014 -- for Debian/Ubuntu, we require significantly longer cycles.<br>
><br>
> This is plain wrong. FFmpeg generally supports release branches that are<br>
> still widely in use. If they aren't there isn't much point in supporting them.<br>
> For example the latest release of the FFmpeg 0.5 series was 0.5.15 in November<br>
> 2014, while the latest release of the Libav 0.5 series was 0.5.10 in February<br>
> 2013, despite being used in Debian squeeze LTS.<br>
><br>
> > Long-term support is not the only problem - I remain unconvinced that<br>
> > switching from Libav to FFmpeg will solve the fragmentation problem. I fear<br>
> > that it would be replaced by fragmentation across different FFmpeg upstream<br>
> > versions. This may or may not be true in practice, but this is<br>
> > what both my experience and intuition on this topic tells me.<br>
><br>
> I don't believe there would be more fragmentation than there is currently.<br>
> There could even be the contrary effect: If FFmpeg libraries are available<br>
> in Debian, there is less reason to embed a copy of them.<br>
><br>
> > I'm sure that this issue could be addressed in FFmpeg, I'm just not sure<br>
> > how insistent (and helpful) FFmpeg is here, because this for sure will<br>
> > compromise development velocity, which as written above, is the main<br>
> > disagreement between FFmpeg and Libav in my eyes. Maybe Andreas could<br>
> > comment on this point?<br>
><br>
> How do you think FFmpeg could help in this regard?<br>
> After all, FFmpeg developers can't decide which version Avidemux/MythTV<br>
> uses.<br>
><br>
> >> I am not qualified for technical comparison between ffmpeg and libav.<br>
> ><br>
> > I think nobody really is, because there is no technical metric or similar<br>
> > criteria that could help us here.<br>
><br>
> I disagree. For example, one metric would be to look at fixed issues in<br>
> FFmpeg's bug tracker (e.g. [9]) and open issues in Libav's bug tracker<br>
> (e.g. [10]) and compare.<br>
><br>
> > What are the right questions for assessing FFmpeg vs Libav? Let me try to<br>
> > formulate questions that focus on maintainability:<br>
> ><br>
> > What project is less effort to package?<br>
> > - I'd think Libav, because of the less frequent release cycle. Both<br>
> > projects have rather accessible upstreams.<br>
><br>
> If release frequency really would be a problem, one could simply skip<br>
> some releases.<br>
><br>
> > What project is doing a better job with handling defect reports?<br>
> > - I'd think FFmpeg, because the Libav bug tracking system is currently<br>
> > dysfunctional. AFAIUI this is being worked on. I've worked around this for<br>
> > quite some time by talking to individuals on IRC directly, but this clearly<br>
> > doesn't scale.<br>
><br>
> On the other hand bugs not fixed in Libav, but in FFmpeg, can increase the<br>
> maintenance effort due to more bug reports in the Debian bug tracker.<br>
><br>
> > What project causes less effort for applications?<br>
> > - A significant number of upstream prefer FFmpeg. OTOH, FFmpeg makes great<br>
> > effort to provide source-code compatibility, but obviously a number of<br>
> > projects only develop and test against FFmpeg, so this doesn't help.<br>
><br>
> I'm sure the situation would be far worse if FFmpeg wouldn't make such an<br>
> effort to be compatible.<br>
><br>
> > What project is less effort for the security team?<br>
> > - I'd say Libav, the security patches have significantly better commit<br>
> > messages and descriptions, and generally make much more sense at least to<br>
> > me. Maybe Moritz can elaborate on this.<br>
><br>
> It seems he already did [11]:<br>
> "I think ffmpeg is doing better in terms of handling security issues; when<br>
> I contacted Michael Niedermeyer in private we has always quick to reply,<br>
> while libav-security@ seems understaffed: Several queries in the past needed<br>
> additional poking, some were left unaddressed until today. Also, the Google<br>
> fuzzer guys stated that more samples are unfixed in libav compared to ffmpeg."<br>
><br>
> > My personal impression is that In FFmpeg, security support is handled by a<br>
> > single person whose work is not exactly easy to follow.<br>
><br>
> Michael is not the only one who cares about FFmpeg's security. For example,<br>
> I do as well and I recently fixed a number of issues that I found by fuzzing<br>
> myself. Not all of them are fixed in Libav yet, even though I sent my patches<br>
> also to <a href="mailto:libav-devel@libav.org">libav-devel@libav.org</a>.<br>
><br>
> > For me personally, this looks like a tie.<br>
><br>
> For me it looks like a clear choice.<br>
><br>
> > I would like to think that a<br>
> > high-profile, high-performance and universal multimedia codec and format<br>
> > library deserves a clean code-base, clean documentation, excellent test<br>
> > coverage and a steady and thorough release process. Neither Libav nor<br>
> > FFmpeg achieve that fully. Libav had so much potential, but struggles with<br>
> > achieving it for IMO mostly manpower reasons - working in or with FFmpeg<br>
> > for some reason seems to be more attractive.<br>
><br>
> My main reason for preferring to work on FFmpeg is that it already works better.<br>
><br>
> > Clearly, Libav has lost a lot of its drive when it took off. This drive has<br>
> > significantly diminished - significant contributors from its inception are<br>
> > no longer active. I remain convinced that for the Jessie release, Libav was<br>
> > the better choice.<br>
><br>
> Unfortunately FFmpeg was stuck in the NEW queue until after the transition freeze,<br>
> so for Jessie the choice was between Libav and Libav+FFmpeg, which the security<br>
> team didn't want.<br>
><br>
> > For Stretch, it is less clear. Libav seems to me like<br>
> > the prudent choice, FFmpeg like the more aggressive one.<br>
><br>
> For stretch I think FFmpeg would be the sensible choice, while staying with<br>
> Libav would just be the 'status quo' choice.<br>
><br>
> > I'd rather<br>
> > encourage people to help with porting missing features and bugs to Libav,<br>
> > because it is the cleaner and more maintainable codebase, but given that we<br>
> > are all volunteers, this may or may not happen.<br>
><br>
> I don't think Libav has a much cleaner or more maintainable codebase, it's<br>
> just smaller. Fixing issues in Libav that are already fixed in FFmpeg is<br>
> just duplicated work, which is not very rewarding to do.<br>
><br>
> > Wow, that was a much longer email than I hoped. And given that I'm still<br>
> > traveling and doing many family visits, it also took me much longer to<br>
> > write this than I wished. If we really had to vote right now which way to<br>
> > go, I'd probably abstain, because I also have to face the fact that I no<br>
> > longer have the capacity to support a high-profile package like libavcodec<br>
> > with the same time and devotion as I did for the last 5 years. How ever we<br>
> > as a team decide to move forward, I think libavcodec (and related<br>
> > libraries) are better team maintained (pkg-multimedia is just fine for<br>
> > this), and I'd be happy to help out with the packaging either way.<br>
><br>
> I'm not opposed to pkg-multimedia team maintenance for FFmpeg.<br>
> If anyone wants to help maintaining it, feel free to add yourself as uploader.<br>
><br>
> Best regards,<br>
> Andreas<br>
><br>
><br>
> 1: <a href="https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b3675f890abee0bc446495711223a5c790234672">https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b3675f890abee0bc446495711223a5c790234672</a><br>
> 2: <a href="http://j00ru.vexillium.org/?p=2211">http://j00ru.vexillium.org/?p=2211</a><br>
> 3: <a href="http://thread.gmane.org/gmane.linux.gentoo.devel/95339/focus=95585">http://thread.gmane.org/gmane.linux.gentoo.devel/95339/focus=95585</a><br>
> 4: <a href="https://forums.gentoo.org/viewtopic-t-1010096.html">https://forums.gentoo.org/viewtopic-t-1010096.html</a><br>
> 5: <a href="https://sources.debian.net/src/xbmc/2:13.2%2Bdfsg1-4/lib/xbmc-libav-hacks">https://sources.debian.net/src/xbmc/2:13.2%2Bdfsg1-4/lib/xbmc-libav-hacks</a><br>
> 6: <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=chromium-browser_system-ffmpeg.patch;att=1;bug=763632">https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=chromium-browser_system-ffmpeg.patch;att=1;bug=763632</a><br>
> 7: <a href="https://trac.ffmpeg.org/wiki/Downstreams">https://trac.ffmpeg.org/wiki/Downstreams</a><br>
> 8: <a href="https://sources.debian.net/src/libav/6:11.3-3/doc/RELEASE_NOTES/?hl=9#L9">https://sources.debian.net/src/libav/6:11.3-3/doc/RELEASE_NOTES/?hl=9#L9</a><br>
> 9: <a href="https://trac.ffmpeg.org/ticket/4431">https://trac.ffmpeg.org/ticket/4431</a><br>
> 10: <a href="https://bugzilla.libav.org/show_bug.cgi?id=840">https://bugzilla.libav.org/show_bug.cgi?id=840</a><br>
> 11: <a href="https://lists.debian.org/debian-devel/2014/08/msg00060.html">https://lists.debian.org/debian-devel/2014/08/msg00060.html</a><br>
><br>
> _______________________________________________<br>
> pkg-multimedia-maintainers mailing list<br>
> <a href="mailto:pkg-multimedia-maintainers@lists.alioth.debian.org">pkg-multimedia-maintainers@lists.alioth.debian.org</a><br>
> <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers</a><br>
</p>