|
|
Subscribe / Log in / New account

A Voice from the Other Side

A Voice from the Other Side

Posted Aug 6, 2014 18:37 UTC (Wed) by DonDiego (guest, #24141)
Parent article: Reconsidering ffmpeg in Debian

> He also mentioned ffmpeg's active developer community, implying by omission that libav's community is less so.

Libav is very much alive, churning out regular releases, daily commits, lots of activity on both the development mailing list and IRC channel, and new developers joining. All of the code from libav is merged into FFmpeg without credit or thanks, bolstering FFmpeg's perceived activity.

What libav clearly has less of is brand name recognition. One side of the split managed to grab ahold of the domain name and now presents itself as the original and true FFmpeg. The split created long-lived forks, none of the sides has more legitimacy in claiming to be the true FFmpeg than the other.

> The X.org fork of XFree86, for example, jump-started the development community and led to a rapid modernization of the code and increase in functionality. Three years later, it is not at all clear that the libav fork has succeeded in this way.

For better or worse, and for all the mistakes that are so easy to identify in hindsight, the split was the best thing that happened to FFmpeg in years. Not much different than with X.org vs. XFree86, the development community was jump-started and the code base rapidly modernized including an increase in functionality.

FFmpeg was poorly managed, stagnating, never made formal releases, had strict territorial code ownership, and a number of developers had stopped working on the project, leaving in frustration. Upsetting the dictatorial management structure brought them back and with them a lot of code and energy to work on the centerpiece of FOSS multimedia. Both projects have since moved to more modern tools and development practices.

Libav has led a big number of long-overdue overhauls of the library APIs, large-scale refactorings, and cleanups that included throwing away cruft and functionality that was not worth the maintenance burden. Before, attempts to do the same in the old project failed.

> In particular, the fuzzing work done at Google has led to over 1,000 separate bugs being fixed in ffmpeg.

The security issue is a complete red herring. It's quite simple really, both are horrid. Whether or not one has 1000 crashers and the other only 900 or the other way around is immaterial when the supply of bugs is basically infinite. If 1000 bugs get fixed, one should start to wonder how so many got there in the first place and how many more might be lurking.

Much of the old codebase was written during times when error checking was considered an optional nuisance or directly skipped to speed up decoding. Fuzzing is a great way to find bugs, but there is plenty to be found with good old grep or opening a random source file in your favorite editor and reading. Maybe we will live to see the day when the libraries are robust, but at this point it is very far off in the future. Adding all that error checking is not that much fun nor likely to make you rich or a featured celebrity.

Also note that many of the CVEs and bugs fixed in FFmpeg simply do not apply to libav or get fixed there in a more thorough fashion.

> compatibility problems between libav and programs like mplayer and the XBMC media center system.

Forget MPlayer, its successor mplayer2 and mpv, the successor of mplayer2, are much better. The codebase was cleaned up of old cruft while adding useful features. I put countless hours over many years into MPlayer, yet I'm not missing it. MPlayer did not age all that well, it is keeping its userbase and developers through gravity mostly. People don't switch because they have never heard of the alternatives. If MPlayer leaving Debian gives the alternatives a place in the spotlight, all the better.

XBMC (now called Kodi apparently) works with libav the last time I checked. In any case packaging Kodi/XBMC for Debian is going to be a gargantuan undertaking. Debian forbids embedded library copies of which XBMC has a metric gigaton.

> defenders of libav were mostly conspicuous in their absence.

Conspicuously absent are members of the libav community with the willingness or energy to join the next - this time on a Debian mailing list - trollfest. But unfortunately nobody seems to notice a lack of negativity, neither now nor at any of the previous occasions. People seem to prefer forming their opinion by reading mudslinging in random forums[1] rather than by reading patches, and by all accounts the mud does stick.

[1] No, this is not a thinly-veiled reference to lwn.net.


to post comments

A Voice from the Other Side

Posted Aug 7, 2014 5:27 UTC (Thu) by tzafrir (subscriber, #11501) [Link] (4 responses)

The thread on debian-devel has mostly been a civil discussion. Yet I can't recall of a single valid argument that was raised there for keeping libav The only partial exception I recall "It's already in Stable. We have to keep it for as long as we support Stable anyway." which is somewhat valid, but may also be throwing good money after bad money (if libav is the worse choice of the two).

Oh: and that there's a single package (gstreamer-libav(?)) that only builds with libav and not with ffmpeg (while there are a number of other packages in the other direction).

Now, would you (or any other libav developer) kindly respond there? Or should Debian just replace libav with ffmpeg, given that no decent counter arguments were presented?

A Voice from the Other Side

Posted Aug 7, 2014 12:28 UTC (Thu) by Seegras (guest, #20463) [Link] (2 responses)

I think replacing libav with ffmpeg again is the right choice.

Yes, the fork was necessary, if only to keep the ffmpeg-developers on their toes, but I think ffmpeg is much the better choice now. I run debian, and I've used ffmpeg for maybe two years, since libav just did not have the necessary features.

A Voice from the Other Side

Posted Aug 7, 2014 14:42 UTC (Thu) by DonDiego (guest, #24141) [Link] (1 responses)

What features are you missing? I'm certainly missing nothing, as - arguably - are most people since either library versions are very featureful, but we are open to suggestions if you need/want something backported.

A Voice from the Other Side

Posted Aug 8, 2014 9:48 UTC (Fri) by jmm (subscriber, #34596) [Link]

mpv in Debian fails to decode vobsub subtitles, while is works with ffmpeg.

The libav bug is inactive for 1.5 years now: http://bugzilla.libav.org/show_bug.cgi?id=419

A Voice from the Other Side

Posted Aug 9, 2014 18:43 UTC (Sat) by tzafrir (subscriber, #11501) [Link]

A Voice from the Other Side

Posted Aug 7, 2014 11:28 UTC (Thu) by akka (guest, #98110) [Link]

If you look at MPVs site they say they support both but recommend ffmpeg?

A Voice from the Other Side

Posted Aug 7, 2014 16:23 UTC (Thu) by ux (guest, #98231) [Link]

> All of the code from libav is merged into FFmpeg without credit or thanks, bolstering FFmpeg's perceived activity.

Wrong:
• Every download here mentions Libav: http://ffmpeg.org/download.html#releases
• Libav is mentioned in the 2nd paragraph of our last release notes: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=RELEASE_NOTES;...
• Every single commit from Libav is in a merge commit to keep full authorship, even if we don't actually merge the changes.

> Forget MPlayer, its successor mplayer2 and mpv, the successor of mplayer2, are much better.

MPlayer is still maintained, mplayer2 is completely dead since months.

A Voice from the Other Side

Posted Aug 7, 2014 21:25 UTC (Thu) by runekock (subscriber, #50229) [Link] (1 responses)

> The security issue is a complete red herring. It's quite simple really, both are horrid. Whether or not one has 1000 crashers and the other only 900 or the other way around is immaterial when the supply of bugs is basically infinite. If 1000 bugs get fixed, one should start to wonder how so many got there in the first place and how many more might be lurking.

>Much of the old codebase was written during times when error checking was considered an optional nuisance or directly skipped to speed up decoding. Fuzzing is a great way to find bugs, but there is plenty to be found with good old grep or opening a random source file in your favorite editor and reading. Maybe we will live to see the day when the libraries are robust, but at this point it is very far off in the future. Adding all that error checking is not that much fun nor likely to make you rich or a featured celebrity.

Uh-oh, sounds like both libraries are basically impossible to secure in their present states. If that is the case - and DonDiego certainly seems to know what he is talking about - then the Debian security team is providing a false sense of security by supporting (one of) the libraries.

Perhaps it would be better in this case to drop any pretense of security support on the distro level. For Debian, a way to do that would be to keep the libraries out of future stable releases, only providing them in e.g. unstable.

A Voice from the Other Side

Posted Aug 7, 2014 21:49 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

Unfortunately, people want to play videos on their Debian stable systems without having to do some elaborate apt configuration dance.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds