Reconsidering ffmpeg in Debian
FFmpeg is a set of libraries for the handling of files (and streams) containing audio and video data. With its extensive format support, it has long been the definitive library for application developers wanting to work with multimedia streams. It has also, at times, had a history of discord within its development community. Back in early 2011, strong disagreements within this project led to a hostile fork which, eventually, picked up the name libav. Initially the two projects worked with nearly identical code, but they have drifted apart over time.
The Debian distribution chose early on to drop ffmpeg and go with libav. This decision was made in typical Debian style; the Debian developer who maintained ffmpeg was part of the group that created the fork, so he naturally pulled the distribution along for the ride. For the most part, Debian users have not really noticed the change; things generally just work, though, recently, the mplayer video player application has run into trouble due to its being primarily written and tested for ffmpeg rather than libav. Other programs, too, occasionally show signs of their developers paying more attention to working with ffmpeg.
Recently, Andreas Cadhalpun proposed a plan to bring the ffmpeg system back into the Debian distribution. He had a number of reasons for wanting to have ffmpeg in the repository, including compatibility problems between libav and programs like mplayer and the XBMC media center system. There are, he said, a number of features in ffmpeg that have not found their way into libav; these include the "deshake" image stabilization filter and a number of codecs. He also mentioned ffmpeg's active developer community, implying by omission that libav's community is less so. The plan for bringing back ffmpeg has been carefully designed to avoid breaking programs that currently depend on libav. FFmpeg would be carefully installed so that it could live alongside libav and applications could be built against either.
The discussion that ensued made it clear that a number of Debian developers would like to see ffmpeg as part of the distribution again. Indeed, defenders of libav were mostly conspicuous in their absence. It would seem that, in the three years and some since the fork, libav has lost a lot of its charm, at least in the Debian community. Given Debian's tendency toward including almost anything if a developer wants to maintain it, one would think that putting ffmpeg back would be uncontroversial. In the reality, though, it is still not clear that ffmpeg will be returning in the near future.
The sticking point would appear to be security support. FFmpeg is seen by
many as having rather more than its share of security problems; as a
result, the Debian security team is nervous about adding ffmpeg support to
their workload. It is worth noting that nobody has said that libav is
better in this respect; indeed, Debian security team member Moritz
Muhlenhoff stated that he thinks ffmpeg
is more responsive to security issues than libav. The point is that
either package brings in a fair number of problems to be solved, so
doubling the load is not welcome. As Moritz put
it last February: "for libav/ffmpeg this simply isn't manageable
at all due to the huge stream of security issues trickling in
".
There are a number of reasons why a project like ffmpeg (or libav) will have more than the average number of security-related problems. The library is directly exposed to potentially hostile data in the form of audio and video streams controlled by others. The number of formats to be supported is huge, and many codecs are written by developers who may not have security at the top of their list of concerns. Performance requirements can lead to hardware-specific code, sometimes done in assembly. Multimedia libraries find their way into a wide range of other applications, so a vulnerability can show up in unexpected places. It is thus not entirely surprising that a project like ffmpeg would have a relatively large number of security issues.
Even so, one might argue that the number is too large, and that the project should be doing better. The answer here is that, with some help from Google, both ffmpeg and libav are indeed trying to do better. In particular, the fuzzing work done at Google has led to over 1,000 separate bugs being fixed in ffmpeg. Many of those were security-related, of course; that, too, will increase the number of security fixes released by the project.
So ffmpeg should be getting better, and, by most accounts, libav is trying to follow the same path. That fact may calm some worries about accepting ffmpeg back into Debian in general, but it still is unlikely to make the security team feel better about its increased workload. So if ffmpeg comes in, it may well have to be at the expense of libav, a change that was not part of the posted plan for restoring ffmpeg.
If the debian-devel discussion is a proper guide, there will be few tears shed if ffmpeg edges libav out of the distribution. But, of course, there is a hitch here: the freeze date for the upcoming "jessie" release is a mere three months away. That is not a long time to replace a core library depended on by a large number of applications. If this replacement is to happen, it needs to start right away. If it does not happen soon, libav is likely to be the only option in Debian for another two years or so.
As of this writing, no clear resolution is in sight. There have been suggestions that this issue should be referred to the Debian technical committee, even though it cannot honestly be said that the requisite efforts to achieve consensus within the development community have been made.
Forks, if done right, can bring extensive benefits to both developers and
users. 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. Instead, it presents
distributors with an unpleasant choice: either try to pick a winner or
double up on an already extensive security update stream. Regardless of
how it chooses, Debian is going to have a fair amount of work to do as it
straightens out its short- and long-term plans regarding multimedia
support.
Posted Aug 5, 2014 20:46 UTC (Tue)
by marduk (subscriber, #3831)
[Link] (3 responses)
Ideally these packages would either merge back into one or one should just die. As an end user I don't completely understand all the politics behind the fork but it is rather frustrating.
Posted Aug 5, 2014 21:11 UTC (Tue)
by josh (subscriber, #17465)
[Link] (2 responses)
Does anything only support libav at this point, other than libav's own tools?
Posted Aug 5, 2014 21:52 UTC (Tue)
by marduk (subscriber, #3831)
[Link]
I think in the Gentoo world, no. But sometimes upstream will only support one or the other.
For example, gstreamer's gst-libav plugin. It *used* to be called gst-ffmpeg. But upstream only supports libav now. Usually it works fine with ffmpeg. ffmpeg 2.3 comes out, now gst-libav doesn't work. User are forced to either stick with ffmpeg 2.2 or lower or switch to libav. Upstream doesn't officially support ffmpeg, so it will probably have to wait until Gentoo or someone else comes up with an unofficial patch.
Posted Aug 12, 2014 12:00 UTC (Tue)
by KotH (guest, #4660)
[Link]
Posted Aug 6, 2014 5:39 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (4 responses)
Posted Aug 6, 2014 7:35 UTC (Wed)
by jezuch (subscriber, #52988)
[Link] (3 responses)
Could someone remind us *what* led to the fork? I didn't realize it's been three years already...
Posted Aug 6, 2014 11:26 UTC (Wed)
by Siosm (subscriber, #86882)
[Link] (2 responses)
Posted Aug 12, 2014 11:55 UTC (Tue)
by KotH (guest, #4660)
[Link] (1 responses)
Posted Aug 12, 2014 12:15 UTC (Tue)
by ux (guest, #98231)
[Link]
I would guess that's what Siosm was pointed out to answer the question from jezuch.
Posted Aug 6, 2014 9:58 UTC (Wed)
by kugel (subscriber, #70540)
[Link] (1 responses)
Posted Aug 6, 2014 14:46 UTC (Wed)
by nevets (subscriber, #11875)
[Link]
Posted Aug 6, 2014 10:21 UTC (Wed)
by przemoc (guest, #67594)
[Link] (9 responses)
tl;dr FFmpeg is mostly superset of libav when it comes to features, but due to merges from diverging libav code base, to preserve being as compatible as possible, it's API is somewhat dictated by libav and there is some ABI bloat. OTOH FFmpeg can be seen as too easily accepting and putting new stuff in (not necessarily ready for wider audience).
And mpv is currently the best video player in Linux, actively developed with a lot of stuff cleaned and sanitized (and sometimes removed) from MPlayer+mplayer2's heritage. It has also encoding capability, but it's not feature complete yet.
Posted Aug 6, 2014 12:38 UTC (Wed)
by clump (subscriber, #27801)
[Link] (6 responses)
Posted Aug 6, 2014 14:15 UTC (Wed)
by DonDiego (guest, #24141)
[Link] (2 responses)
Posted Aug 7, 2014 11:18 UTC (Thu)
by akka (guest, #98110)
[Link] (1 responses)
Posted Aug 7, 2014 11:26 UTC (Thu)
by DonDiego (guest, #24141)
[Link]
Posted Aug 6, 2014 15:15 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Aug 7, 2014 11:42 UTC (Thu)
by gidoca (subscriber, #62438)
[Link] (1 responses)
Posted Aug 7, 2014 13:39 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
[1]https://github.com/mpv-player/random-stuff/tree/master/ma...
Posted Aug 6, 2014 19:45 UTC (Wed)
by patrick_g (subscriber, #44470)
[Link]
What are the advantages of mpv over VLC ?
Posted Aug 7, 2014 11:21 UTC (Thu)
by akka (guest, #98110)
[Link]
<Although mpv attempts to work well with both FFmpeg and Libav, FFmpeg is preferred in general. This is simply because FFmpeg merges from Libav, and seems to have more features and fewer bugs than Libav. Although we don't agree with everything FFmpeg does, and we like some of Libav's general goals and development directions, FFmpeg is just better from a practical point of view.>
Posted Aug 6, 2014 11:51 UTC (Wed)
by rsidd (subscriber, #2582)
[Link] (17 responses)
Posted Aug 6, 2014 13:27 UTC (Wed)
by DonDiego (guest, #24141)
[Link] (15 responses)
Posted Aug 6, 2014 20:45 UTC (Wed)
by ldarby (guest, #41318)
[Link] (1 responses)
cdrecord -scanbus
Posted Aug 7, 2014 4:08 UTC (Thu)
by rsidd (subscriber, #2582)
[Link]
Posted Aug 7, 2014 4:07 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (12 responses)
Posted Aug 7, 2014 14:38 UTC (Thu)
by DonDiego (guest, #24141)
[Link] (11 responses)
FFmpeg merged all those changes and subsequently decided to take the new core and rename it back to the old name, dropping the compatibility wrapper. So there really are two avconv tools now, under two different names, from two different projects.
Why people get so worked up about a deprecation warning is beyond me. None of us care what the FFmpeg projects calls their command line tools. avconv(ert) is a more descriptive name IMO, but FFmpeg can certainly choose whatever name they prefer. It would be nice if we were granted that same freedom of renaming the tools we ship, doubly nice if we could add compatibility wrappers under the old name(s) to ease the transition for our users.
We don't make statements about the FFmpeg project in the output of our command line programs. If an FFmpeg developer constructs the output as "lies" about the FFmpeg project, well, I cannot help it.
There are two projects that both see themselves as the legitimate successor of the FFmpeg project from before the split. Both have had a command line tool called "ffmpeg" for multiple releases. Why we are not allowed to rename ours (and ship a wrapper) is beyond me. It is also beyond me why we should have to mention that our version is not from them. Yes, this Coca Cola was not produced by Pepsi. Their ffmpeg tool does not say "this is a renamed version of the avconv tool from libav" either.
Since you seem to consider this renaming charade so offensive maybe you should also go look at the other side: If you go to the FFmpeg download page at http://www.ffmpeg.org/download.html you will see news about releases that include the names and versions of included libraries. Conspicuously missing from that list is libavresample, which FFmpeg also ships but which originated in the libav project. There is a report in FFmpeg's issue tracker about the missing library version on the download page: https://trac.ffmpeg.org/ticket/3774 - the response is that libavresample is "unmaintained" and "should not be used". libavresample is very much maintained, just not by FFmpeg. Why should it not be used? Maybe because programs using libswresample instead become incompatible with libav?
So, what do you call that?
Posted Aug 7, 2014 15:45 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (6 responses)
It is not normal to do that when the unforked program with the same name still exists. It is as if LibreOffice forked OpenOffice (for perfectly good reasons), kept around the "ooffice" binary (again for perfectly good reasons of compatibility), but if you typed "ooffice", warned that OpenOffice was "deprecated" -- even though Apache OpenOffice was alive and well and making releases, despite admittedly being dormant earlier. Or maybe you don't see that as a problem.
Since you bring up that analogy (and ignoring questions of trademarks) -- it is as if Pepsi forked from Coca Cola, produced a "similar" product called Coca Cola for a while, and then told people who asked for coke that "Coca Cola is deprecated and will be removed in the future".
First, if other people act like jerks that doesn't mean you need to act like one. Second, ffmpeg (unlike libavsample) is meant to be used by end-users and it is unlikely that end-users will see the message you quote on the issue tracker page.
Posted Aug 7, 2014 16:16 UTC (Thu)
by DonDiego (guest, #24141)
[Link] (5 responses)
> It is not normal to do that when the unforked program with the same name still exists. It is as if LibreOffice forked OpenOffice (for perfectly good reasons), kept around the "ooffice" binary (again for perfectly good reasons of compatibility), but if you typed "ooffice", warned that OpenOffice was "deprecated" -- even though Apache OpenOffice was alive and well and making releases, despite admittedly being dormant earlier.
The program printed a deprecation message because the command line syntax changed, scripts might need to get updated, etc. This was not a case of just symlinking the two names.
Why do keep insisting that a simple heads-up message to users was done out of malice to spite a competing project?
Also note that "ffmpeg" (lowercase, command line program) is not equal to "FFmpeg" (mixed case, project name). While this might seem silly and inconsequential to you, nobody in either community confuses the two names.
> > Yes, this Coca Cola was not produced by Pepsi.
> Since you bring up that analogy (and ignoring questions of trademarks) -- it is as if Pepsi forked from Coca Cola, produced a "similar" product called Coca Cola for a while, and then told people who asked for coke that "Coca Cola is deprecated and will be removed in the future".
You argue from the asssumption that one of the two sides of the split is the original and the other is the fork. This is not the case here. Both sides claim to be the legitimate successors of the original FFmpeg project. Who forked who is very much disputed.
> > maybe you should also go look at the other side [libavresample]
> First, if other people act like jerks that doesn't mean you need to act like one.
Of course not, but you act as if one side is misbehaving here while the other side is not.
> Second, ffmpeg (unlike libavsample) is meant to be used by end-users and it is unlikely that end-users will see the message you quote on the issue tracker page.
So telling users that they may need to adapt to a new tool syntax is not OK, but telling developers that a library is unmaintained and should not be used is OK?
Posted Aug 7, 2014 22:16 UTC (Thu)
by ldarby (guest, #41318)
[Link] (4 responses)
Because that's precisely what it looks like to people outside your community.
Posted Aug 7, 2014 22:37 UTC (Thu)
by DonDiego (guest, #24141)
[Link] (3 responses)
> Because that's precisely what it looks like to people outside your community.
Well, appearances can be deceiving.
Posted Aug 8, 2014 17:52 UTC (Fri)
by flussence (guest, #85566)
[Link] (2 responses)
In this version of reality it would be a no-brainer to just quietly remove the offending message than to continue trying to justify it with increasingly ridiculous excuses. The damage to libav's reputation stops, new users turning to Google for a straight answer don't have to inadvertently discover that one Ubuntu bug or the entire bloody history of the libav project's existence. The project wouldn't even need to issue a public apology for causing confusion over this; people would just forget after a while.
But those are pretty huge and baseless assumptions, I'll admit.
Posted Aug 8, 2014 21:21 UTC (Fri)
by DonDiego (guest, #24141)
[Link] (1 responses)
I'll be glad to hear your alternative wording suggestions. Make it express that the ffmpeg command line program has been deprecated in favor of the avconv command line program due to incompatible command line syntax improvements.
Posted Aug 8, 2014 21:24 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link]
Posted Aug 7, 2014 16:51 UTC (Thu)
by ux (guest, #98231)
[Link] (3 responses)
FFmpeg merged avconv changes in his main tool called "ffmpeg" from the beginning. But ffmpeg also has a compatiblity layer for the old options, see opt_old2new() in ffmpeg_opt.c.
> Why people get so worked up about a deprecation warning is beyond me. None of us care what the FFmpeg projects calls their command line tools.
You suddenly seems to forget that Libav was (is?) packaged for years in debian under the package name "ffmpeg", and thus was suggesting the FFmpeg project was renamed (which is actually what the original post on lwn said).
FFmpeg didn't get renamed but continued being developed, and thus didn't renamed its main tool nor its libraries.
Libav is another new project, and kept the tool name for a while, and still has the same library names thanks to the confusing name of "Libav".
> There is a report in FFmpeg's issue tracker about the missing library version on the download page: https://trac.ffmpeg.org/ticket/3774 - the response is that libavresample is "unmaintained" and "should not be used".
Comment from Carl Eugen "fixed" in https://trac.ffmpeg.org/ticket/3774#comment:7
Sorry about that.
Posted Aug 7, 2014 17:08 UTC (Thu)
by DonDiego (guest, #24141)
[Link] (2 responses)
> FFmpeg didn't get renamed but continued being developed, and thus didn't renamed its main tool nor its libraries.
You derive all the legitimacy of calling yourself the real FFmpeg project from somehow having got ahold of the domain name. There are two projects now, both of which see themselves as legitimate successors of the FFmpeg that was there before. Either both should have a claim to the title or none should. One side says it's a fork, the other a rename.
Complaining about this is just disingenuous. Pot, kettle, black...
Posted Aug 7, 2014 17:35 UTC (Thu)
by ux (guest, #98231)
[Link] (1 responses)
The name of the project didn't change and continued its development under the same name, with less developers. Libav is a new project, with a new name, and thus should just assume its fork status. Note that there is absolutely nothing wrong about forking when it's done properly.
Actually, this is from https://libav.org/about.html:
> Later we have learned that the FFmpeg founder, who owns the domain, still favors the now-demoted project leader. We of course respect his opinion, which convinced us to fork "properly" under the name Libav
There is no point in arguying here that Libav is the original project since your official page states that it's a fork.
Posted Aug 7, 2014 17:43 UTC (Thu)
by DonDiego (guest, #24141)
[Link]
Posted Aug 7, 2014 11:33 UTC (Thu)
by akka (guest, #98110)
[Link]
Posted Aug 6, 2014 16:49 UTC (Wed)
by amit (subscriber, #1274)
[Link] (4 responses)
It won't find all the security bugs arising out of improper handling of input streams, but would at least flag places which rely on user-controllable input that look suspicious, and that will give the developers a thought about the security aspect there.
Also, after the heartbleed fiasco, coverity is gaining some smarts in recognizing places that accept user input, so it's only a good thing to point coverity to a codebase that handles a lot of potentially hostile input.
Posted Aug 6, 2014 17:00 UTC (Wed)
by JGR (subscriber, #93631)
[Link]
Posted Aug 6, 2014 19:01 UTC (Wed)
by markh (subscriber, #33984)
[Link] (2 responses)
ffmpeg: https://scan.coverity.com/projects/54
Posted Aug 7, 2014 16:27 UTC (Thu)
by ux (guest, #98231)
[Link] (1 responses)
Coverity is quite nice BTW.
Posted Aug 13, 2014 8:55 UTC (Wed)
by ber (subscriber, #2142)
[Link]
Made me look into stand-a-lone Free Software security checking tools like cppcheck, flawfinder or ASan/TSan/MSan.
Posted Aug 6, 2014 18:37 UTC (Wed)
by DonDiego (guest, #24141)
[Link] (9 responses)
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.
Posted Aug 7, 2014 5:27 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link] (4 responses)
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?
Posted Aug 7, 2014 12:28 UTC (Thu)
by Seegras (guest, #20463)
[Link] (2 responses)
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.
Posted Aug 7, 2014 14:42 UTC (Thu)
by DonDiego (guest, #24141)
[Link] (1 responses)
Posted Aug 8, 2014 9:48 UTC (Fri)
by jmm (subscriber, #34596)
[Link]
The libav bug is inactive for 1.5 years now: http://bugzilla.libav.org/show_bug.cgi?id=419
Posted Aug 9, 2014 18:43 UTC (Sat)
by tzafrir (subscriber, #11501)
[Link]
Posted Aug 7, 2014 11:28 UTC (Thu)
by akka (guest, #98110)
[Link]
Posted Aug 7, 2014 16:23 UTC (Thu)
by ux (guest, #98231)
[Link]
Wrong:
> Forget MPlayer, its successor mplayer2 and mpv, the successor of mplayer2, are much better.
MPlayer is still maintained, mplayer2 is completely dead since months.
Posted Aug 7, 2014 21:25 UTC (Thu)
by runekock (subscriber, #50229)
[Link] (1 responses)
>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.
Posted Aug 7, 2014 21:49 UTC (Thu)
by mpr22 (subscriber, #60784)
[Link]
Posted Aug 8, 2014 22:16 UTC (Fri)
by mhartzel (guest, #91618)
[Link]
Forgive me for being blunt, but this fork really got to my nerves. The ffmpeg / libav maintainer forced libav down every Ubuntu and Debian users throat. This is unacceptable. The choice should have been left to users. I was forced to adapt my software for libav, since I have promised my software package works on Ubuntu and Debian. I was not happy for the extra work.
Yes, libav accelerated ffmpeg development, thanks for that. But now I hope libav just goes away. I can not accept the way libav treated users in this fork. A project should always put its users first. It is not ok to use confusing deprecation messages, or confusing runtime names. Its not ok to fork projects and use a similar name for the fork and claim it is the successor of the original project (mplayer / mplayer2). It is not ok to muddy the waters for the users or try to grab an existing userbase by force. Users must be earned by making good code and being respectable and trustworthy. Libav lost my trust by the way they made things hard and confusing for me as a user and developer.
This fork will go down to history books as an example of how not to do a fork.
Sorry for the rant, this is no troll. I was deeply touched by this fork, and it still brings up bad feelings.
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav
Reconsidering ffmpeg in Debian
mpv / mplayer2
mpv / mplayer2
mpv / mplayer2
Reconsidering ffmpeg in Debian
> Matroska's ordered chapter support [...] mplayer and mplayer2 both lack itReconsidering ffmpeg in Debian
The MPlayer2 website specifically lists Matroska's ordered chapters as one of the improvements over the original MPlayer.
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Forks are all very well, but what I dislike is this sort of message when I type "ffmpeg" in debian/ubuntu:
Reconsidering ffmpeg in Debian
ffmpeg version 0.8.9-6:0.8.9-0ubuntu0.13.10.1, Copyright (c) 2000-2013 the Libav developers
built on Nov 9 2013 19:09:46 with gcc 4.8.1
*** THIS PROGRAM IS DEPRECATED ***
This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.
Suggesting that ffmpeg is deprecated/unmaintained, rather than leading a separate existence independent of the libav developers, is just sneaky.
command line tool deprecations
command line tool deprecations
Cdrecord-Clone 2.01-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg
Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to
...
Note: The author of cdrecord should not be bothered with problems in
this version.
scsidev: 'ATA:'
devname: 'ATA'
scsibus: -1 target: -1 lun: -1
Warning: Using badly designed ATAPI via /dev/hd* interface.
command line tool deprecations
There is very much a non-deprecated ffmpeg command line tool, it's just not from the libav project. If it had said "this ffmpeg command is not from the ffmpeg project, was provided by libav for compatibility, and is deprecated", that would be accurate. What it says is -- well, I said sneaky, but Siosm's link above calls it "a very destructive lie". Call it what you like, it's not nice.
command line tool deprecations
command line tool deprecations
command line tool deprecations
Libav moved to an incompatible command line syntax but kept a wrapper tool with the old syntax and the old name for a transition period. It is perfectly normal for such a compatibility wrapper to warn that its availability into the future is limited and what its replacement is.
Yes, this Coca Cola was not produced by Pepsi.
maybe you should also go look at the other side [libavresample]
command line tool deprecations
command line tool deprecations
command line tool deprecations
command line tool deprecations
command line tool deprecations
I think "The ffmpeg command line program has been deprecated in favor of the avconv command line program due to incompatible command line syntax improvements.", with no obnoxious shouty caps, expresses that concept very well.
command line tool deprecations
command line tool deprecations
command line tool deprecations
command line tool deprecations
command line tool deprecations
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Expecting a tool to "easily" find all "bad-code" related bugs seems somewhat optimistic to me.
Arguably the bulk of ffmpeg/libav is in some way involved in handling user-controllable input (ie. audio/video input).
Reconsidering ffmpeg in Debian
libav: https://scan.coverity.com/projects/106
Reconsidering ffmpeg in Debian
Reconsidering ffmpeg in Debian
Those are significant drawbacks.
A Voice from the Other Side
A Voice from the Other Side
A Voice from the Other Side
A Voice from the Other Side
A Voice from the Other Side
A Voice from the Other Side
A Voice from the Other Side
A Voice from the Other Side
• 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.
A Voice from the Other Side
Unfortunately, people want to play videos on their Debian stable systems without having to do some elaborate apt configuration dance.
A Voice from the Other Side
Reconsidering ffmpeg in Debian