Why Debian returned to FFmpeg

by vezzy-fnord • 11 years ago

265 100 11 years ago

callesgg• 11 years ago

In almost every use case i have i have, libav has not been able to fulfill my needs and i have had to get rid of libav and install ffmpeg.

_delirium3• 11 years ago

Do you have examples? I currently have libav on my Debian machines and ffmpeg on my Ubuntu machines, but haven't really noticed a difference for my needs. I'm not doing anything too complex, admittedly.

simcop2387• 11 years ago

One that I've encountered is that I had trouble setting up live streaming to youtube with libav. Something weird with the rtmp code, with ffmpeg it worked out of the box. Not sure if it matters that it was on a raspberry pi.

roghummal5• 11 years ago

Most of what I do with ffmpeg is change containers.

Example: ffmpeg -i doom4_trailer.mkv -acodec copy -vcodec copy doom4_trailer.mp4

Pretty simple, right?

libav:

[mp4 @ 0xa33800] Application provided invalid, non monotonically increasing dts to muxer in stream 0: -83 >= -83
av_interleaved_write_frame(): Invalid argument

(premature exit)

pvaldes• 11 years ago

Same with me, ffmpeg worked accurately and was extensively documented. Then a day there was no more here. I tried to understand the reasons and adopt avconv despite the ego wars, and those irritant message, and the cumbersome new syntax, and the lack of tutorials in internet... but finally the problem is that avconv just did not worked, and nobody really knew what to do with it.

In the end I stopped using both programs. One was aparently unsafe and not installable without breaking things, and the other reinstall itself constantly, acts in a questionable way, and did not solve my problems. I guess that for Debian this was a false step that consumed time and resources but did more damage than good. Libav probably damaged also the image and dominant position of VLC. After several errors and troubles since them, its current luster is not the same as in the first years in my opinion.

wmantly• 11 years ago

About time, libav has never meet my needs.

andmarios2• 11 years ago

As a Gentoo user, libav only gave me trouble. It was incompatible with many packages, whereas ffmpeg was with none I encountered. The switch to libav was horrific and I never managed to resolve all the issues it created with my system. For some months, updating my system was a herculean task due to libav causing constant —and largely unsolved— trouble. I was really happy to see Gentoo return to ffmpeg. Everything works smooth once again.

I can't comment on code quality, project management, etc and frankly I don't care. If one library causes problems to every bit of my system, it should stay off until it is on par with the library it tries to replace —provided that both libraries use a free software compatible license.

tanderson92• 11 years ago

Can't you choose libav / ffmpeg as you see fit on Gentoo machines ?

TheDong2• 11 years ago

Yes. Gentoo changed the default profile's use flags to include "libav", but adding USE="-libav" would get you back to the ffmpeg world.

Gentoo has supported both for as long as its included libav at all.

TheDong2• 11 years ago

Yes. Gentoo changed the default profile's use flags to include "libav", but adding USE="-libav" would get you back to the ffmpeg world.

Gentoo has supported both for as long as its included libav at all.

andmarios2• 11 years ago

Νear the end of 2014, libav became the default library. Until then it was up to the user to choose, so most of us were with ffmpeg due to our old use flags.

Given the new status quo, my system refused to update since it would pull both libav due to the new profile and ffmpeg due to my use flags. As the Gentoo devs made this new choice, I thought I should embrace it, so I followed the steps to switch to libav. This created a nightmare of dependency issues that took me months to solve, especially given my limited time and that this happened on my main machine. I finally switched back to ffmpeg but it seemed to me that only when it —libav— was removed from Gentoo's default desktop profile my problems really stopped.

JoshTriplett3• 11 years ago

That problem existed in both directions. Packages written to ffmpeg would have trouble building with libav, and packages written to libav would have trouble building with ffmpeg. For an example of the latter, gstreamer adapted its ffmpeg plugin to become a libav plugin, and that plugin now doesn't always build against ffmpeg without some effort.

zimbatm2• 11 years ago

Michael is just amazing. I once had a bug with ffmpeg which he helped me pin down on IRC and then produced a patch for it immediately.

I was disappointed of how aggressive the libav guys where during the fork. They changed the content of ffmpeg.org (which they had legitimate access to) to claim that libav was now the new name of the project. Then they replaced the ffmpeg package in Debian with their own version.

It's entirely possible to maintain both packages in Debian with the alternatives framework. This whole false dichotomy and calling ffmpeg the fork is not helpful in my opinion. So I'm glad that ffmpeg is getting it's package back. Forks are good and should stand on their own merit instead of doing politics like that.

camperman2• 11 years ago

When I was told that ffmpeg was deprecated by libav, I immediately checked whether this was the truth. It wasn't. Bye bye libav - forever. Don't ever lie to your end users.

plorkyeran3• 11 years ago

The libav version of the command line tool named "ffmpeg" was in fact deprecated and has since been removed entirely. The message was confusing due to that there are several different things named "ffmpeg", but it was not untrue.

_delirium3• 11 years ago

It's entirely possible to maintain both packages in Debian with the alternatives framework.

The Debian security team vetoed this option, which is why the recent discussion was choosing between, 1) bring back ffmpeg and remove libav, or 2) keep libav and do not bring back ffmpeg (option 1 was chosen). They don't want to support security patches for both, and for all combinations of software that might use either one.

listic• 11 years ago

The Debian security team vetoed this option

On what grounds?

zimbatm2• 11 years ago

Good point. Reality is more fine-grained than the account of my own perception.

Do you know if contrib packages are also getting security updates ? If no then why didn't they just move the ffmpeg package there. To me it felt like the really wanted the ffmpeg package to be virtual and pointing to libav.

Daviey• 11 years ago

It's entirely possible to maintain both packages in Debian with the alternatives framework.

It isn't quite as simple as this when we are talking about libraries... Which one is used by other packages to build against?

Whichever is used, has to become the runtime dependency.

davmre• 11 years ago

Replacing runtime dependencies is doable for dynamically linked libraries as long as they provide the same ABI, e.g., you can swap out BLAS implementations in this way. Obviously static linking is a different story.

perlgeek• 11 years ago

It's entirely possible to maintain both packages in Debian with the alternatives framework.

It is, but it is also a big maintenance burden, in particular for the security team.

cookiecaper4• 11 years ago

https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav gives an interesting perspective. Libav sounds like it's strict about good software practices and merciless in its exclusion and deletion of "bad" code. This may make a cleaner, more sustainable product over the long term, but it makes compatibility a nightmare now, which is probably why distro managers are increasingly interested in swapping libav back out. Perhaps if they had a more steady, formal release cycle it wouldn't be annoying and they'd have been able to maintain their position in the distros they got to carry them (I think almost all of them have reverted to ffmpeg as the default now). Since libav aggressively deletes old stuff and painstakingly reviews each patch (according to this article, no direct experience), they don't merge a lot of "new stuff" from ffmpeg.

ffmpeg has maintained compatibility, making it really easy for downstream users and distro maintainers to keep going, whilst continuously adding new features and improvements, including aggressively merging those placed in libav (I guess as long as they aren't deletions or cleanups?).

I feel like there's a lot to learn in this whole drama and that it hasn't been very deeply explored. libav team originally claimed that ffmpeg's leadership had gone dark/fallen off the map, but they sure came back quickly to express discontentment at the mutiny. libav team undoubtedly has talented people working on it (wasn't DarkShikari on the libav side of the schism?) and libav/ffmpeg share a lot of goals. You'd think they could come to some type of compromise less onerous than this entire saga has been. IMO it's a failure from all sides that this fork was even a thing. A phased, unified, slow, and well-managed release process like Python 2 -> Python 3 might have made all of this unnecessary.

McGlockenshire• 11 years ago

You'd think they could come to some type of compromise less onerous than this entire saga has been.

Given that the schism was based on politics and philosophy, I doubt that a compromise would have been possible.

ffmpeg moves fast and sometimes gets sloppy, and was hard to version for distros. libav wanted slow and careful and clean and wanted to be distro friendly.

Clearly libav tried to Do It Right(tm), but it looks like they ended up on the losing side of the fork. Forks only work when you can get the majority of developers to come along with you.

dtech2• 11 years ago

Also, according to a ffmpeg contributor [1] (who joined after the schism) they just refused to merge anything by ffmpeg, often doing identical functionality from scratch (because users wanted it after seeing it in ffmpeg).

Meanwhile ffmpeg merged basically everything from libav. Furthermore ffmpeg made an effort to provide compatibility, even for stuff where libav intentionally broke compatibility.

So basically ffmpeg benefitted from all the work put into libav but not the other way around. Seems to me that they brought this upon themselves.

[1] http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html

cookiecaper4• 11 years ago

Obviously the fork was politically driven. That doesn't mean that compromise was impossible. If both sides had more respect for the concern of the other, there's no reason an aggressive ffmpeg hygiene project couldn't have been officially sanctioned. They could've kept the mainstream API and developed a plan to release the cleaned, backwards-incompatible next-gen API in a way that would've actually seen adoption. libav is doing good cleanup work, but the fact that there is a political barrier the participants haven't been able to amicably dissolve is going to stop us from benefiting from it, and that's a real shame.

venantius• 11 years ago

A phased, unified, slow, and well-managed release process like Python 2 -> Python 3 might have made all of this unnecessary.

This is at total nit, but I really doubt emulating the Python 2 -> Python 3 release process would go high on anybody's list of successful project evolutions. Given that Python 3 was officially released in 2008, it's worth keeping in mind that as recently as 2014 most new projects were still being created in Python 2.x[1]

1. http://www.i-programmer.info/news/98-languages/8269-python-2...

deckiedan• 11 years ago

I'm not sure there is a good way to do a breaking change to a programming language in a good way.

That said, given that python 2.7 is being continued to be maintained - but not with new features - for such a long time, and letting python 3 evolve quite quickly until it's now actually beginning (finally, around 3.5ish) to have features which are really appealing to many users (the async stuff, type hinting, etc), I don't think they've done too badly.

They could have made it quicker to happen, but since python2.7 is still a very good language, and works stably on practially every OS you could want, why try to force a change until people are ready?

People bitch about it [the changeover] a lot - not because it's terrible, but because it's lasting such a long time.

AFAIK, NO mainstream OS is shipping python3 as the main python, or even as a default installed python, yet.

Most big libs work in python3 now.

I reckon in 5 years time python3 should be the default install, with 2.7 as the legacy extra package for people who need it.

One way that could have been helpful (and may even be possible?????) would be a -2k flag for python3 which runs in python2.7 compatibility mode, or something. I dunno.

cookiecaper4• 11 years ago

It's definitely been slow for Python 3 but in my experience most new projects are using it now. The mainstream distributions are planning to make Py3 the default Python in their upcoming releases. Almost all important libraries in Py2 have been ported or replaced by now. There are still some curmudgeons that haven't gotten the memo on Py3, but they'll become almost non-existent over the next year or two.

Python 3 adoption was a little slower than may have been ideal, but I personally think it was a very successful way to implement breaking changes, especially when it could've been a libav/ffmpeg-style mess.

laurentoget• 11 years ago

Am i the only one who is amazed that the library which is supporting a huge share of all video playing on all linux machines appears to be pretty much written by one person?

Sir_Cmpwn• 11 years ago

https://github.com/FFmpeg/FFmpeg/graphs/contributors

659 contributors. There are 14 people with over 1000 commits, 34 with over a hundred. 4 people with over 100K additions/deletions.

pjc50• 11 years ago

Free software relies disproportionally on a small number of people doing it for ideological reasons. It doesn't help that video codec work is particularly difficult and usually patent-encumbered. I'm still not sure whether ffmpeg is entirely non-patent infringing.

AndrewUnmuted• 11 years ago

FFmpeg has some thoughts on this...

    Q: Does FFmpeg use patented algorithms? 
    A: We do not know, we are not lawyers so we are not qualified to answer this. Also we have never read patents to implement any part of FFmpeg, so even if we were qualified we could not answer it as we do not know what is patented. Furthermore the sheer number of software patents makes it impossible to read them all so no one (lawyer or not) could answer such a question with a definite no, those who do lie. What we do know is that various standards FFmpeg supports contain vague hints that any conforming implementation might be subject to some patent rights in some jurisdictions

Source: https://www.ffmpeg.org/legal.html

jtchang• 11 years ago

I don't think the single developer argument should be too much of a concern in an open source project. I saw Michael of ffmpeg had a lot of commits. In my experience with both closed and open sourced projects this is usually the case. There is one person that wrote the majority of the code.

The great thing about open source is that even if they step away it's not like the code is going anywhere. To an end user of ffmpeg it would still continue to function.

I personally had no idea ffmpeg was forked to libav until one day I tried to install it in Ubuntu and was like...wtf. Then I installed libav and went about my day.

DanBC• 11 years ago

His commit rate is high partly because he merges all libav commits too.

JoshTriplett3• 11 years ago

That's covered in the article; the projects both use git, so libav commits are merged with the original committers intact, not under someone else's name.

rsync• 11 years ago

Can ffmpeg play a DVD .iso ?

I don't need menu support or parsing or anything ... I just wonder, can I point it at a DVD .iso and it will play video ?

Bjartr• 11 years ago

Well it can rip DVDs but ffmpeg doesn't display anything, the closest to playing anything ffmpeg can do is stream the media to something else that can then show it on screen. So, to answer the question you asked more directly: No, you can't point ffmpeg at anything and have it play video, because that's not what it does. Things that do that might use ffmpeg underneath depending on exactly what's being done.

gajjanag• 11 years ago

It is true that ffmpeg can't do this directly. However, the ffmpeg project ships with a command line ffplay utility that is a very capable command line interface media player. This uses the libav* libraries of ffmpeg for its work.

On a side note, ffplay has a really neat feature: while playing an audio file using ffplay, it displays a spectrogram by default.

gus_massa2• 11 years ago

I don't like how they interpret the table with the numbers of commits.

I tried this criteria, I divide the committers in three groups:

A) Michael Niedermayer

B) People with more commits in FFmpeg, i.e. Clément Bœsch, James Almer Carl, Eugen Hoyos, ...

C) People with more commits in libav, i.e. Vittorio Giovara, Martin Storsjö, Anton Khirnov, ...

(I supouse there are other commits from people outside the published table, but they are few.)

Statistics:

        libav  FFmpeg
  A)       46    1831
  B)       37    1071
  C)     1074     856
  Tot:   1157   3758

An alternative interpretation is that if tomorrow Michael Niedermayer is hit by a bus, the other committers of FFmpeg still make almost the same numbers of commits than the committers of libav (even ignoring the ported commits).

Complete table:

  Developer           libav   FFmpeg
  ---------------------------------   
  Michael Niedermayer    46    1831
  ---------------------------------   
  Clément Bœsch                 179
  James Almer                   155
  Carl Eugen Hoyos              150
  Andreas Cadhalpun      21     114
  Lukasz Marek                   98
  Paul B Mahol                   93
  Ronald S. Bultje               85
  wm4                    16      83
  Christophe Gisquet             66
  Benoit Fouet                   48
  >>>Subtotal            37    1071
  ---------------------------------
  Vittorio Giovara      294     294
  Martin Storsjö        253     252
  Anton Khirnov         206     197
  Luca Barbato          131     113
  Diego Biurrun          72 
  Rémi Denis-Courmont    32 
  Hendrik Leppkes        17 
  Himangi Saraogi        16 
  Gabriel Dume           16 
  Federico Tomassetti    14 
  Peter Meerwald         12 
  Janne Grunau           11 
  >>>Subtotal          1074     856
  ------------------------------------
  >>>>>>Total          1157    3758

aleksi• 11 years ago

My guess that Michael is (in git terms) committer, not patch author. Would be interesting to see table for authors.

RyJones• 11 years ago

Good point. It's quite difficult to assign authorship automatically. Take a look at this not-yet-merged commit: https://git.allseenalliance.org/gerrit/#/c/4870/ who authored it? Todd. Who has signed off on editing it? Todd and me. How would you assign ownership? By LOC, Todd wrote essentially 100% of the patch, but since I edited it last, my name is last in the list of editors.

buster• 11 years ago

As you can see many of the other major contributors to ffmpeg are also contributors to libav. This is explained that ffmpeg merges back a lot of libav but not so much in the other direction. In other words, if this is true and all major contributors except for Michael are in fact libav developers then ffmpeg might have a hard time when Michael leaves.

But since Michael alone seems to "outdevelop" all others, ffmpeg comes ahead in terms of features and supported codecs, so people prefer ffmpeg. Since i don't know the ffmpeg APIs or the code quality, i don't know if it is true that ffmpeg has the worse design and development process. If it is true and Michael leaves it sounds like a lot work to take over. On the other hand... i understand that libav was already a fork of ffmpeg.. So some people did take over the code in the past.

Just restating what the article says.

gus_massa2• 11 years ago

Perhaps the table is not clear enought. I don't know about the exact members of each group, so I have to guess. I hope nobody get offended if misclassified.

Let's put Michael Niedermayer in his own group "A".

Clément Bœsch has no commits in libav and 179 in FFmpeg. So I guess he's in the FFmpeg team.

Andreas Cadhalpun has 21 in libav and 114 in FFmpeg . So I guess he's in the FFmpeg team.

I put all the persons who have more commits in FFmpeg than in libav in the FFmpeg team. Let's call this team "B". The classification is clear, because in all the cases the difference is big.

Vittorio Giovara has 294 commits in libav and 294 in FFmpeg. It's a tie! It's more difficult to guess, but I put him in the libav team. (This choice makes the bus factor bigger.)

Martin Storsjö has 253 in libav and 252 in FFmpeg. It's also difficult to guess, but I put him in the libav team.

I put all the persons who have more commits in libav in FFmpeg in the libav team. Let's call this team "C". Some cases are difficult to classify, but I choose the classification that makes the bus factor bigger.

In the table:

        libav  FFmpeg
  A)       46    1831
  B)       37    1071
  C)     1074     856
  Tot:   1157   3758

Ignoring the group A) and making a lot of assumptions, the table it can be read as

The persons in group B wrote 1071 commits for FFmpeg and 37 of them were copied to libav

The persons in group C wrote 1074 commits for libav and 856 of them were copied to FFmpeg.

The moral is that with the data of the table it's not clear that the group B is much smaller than group C. Only that group A is bigger than both!

crystalgiver2• 11 years ago

Yet another instance of "worse" is better: https://en.wikipedia.org/wiki/Worse_is_better

wsc981• 11 years ago

I was thinking about that too, when I read the article. It seemed the libav guys are perfectionists, while the ffmpeg guys focus on getting things done.

It made me wonder in my own professional work: should I also focus more on getting things done instead of trying to find the best solution? Will that approach give better results in the end? It's hard to tell if libav is more maintainable in the end, especially if no one will use it in the next few years, which might be the result of Debian backing down on libav.

Still, the fact that ffmpeg has more features and its devs fix bugs and security issues more quickly seem to suggest that ffmpeg is more maintainable, even if the libav maintainer claims otherwise.

---

In the end it's better to work on a (perhaps) less maintainable product that people use compared to a very maintainable product that no one uses.

cpeterso• 11 years ago

Instead of building "perfect software", perfectionist can redirect their focus on finding the "perfect compromise" design. :)

smtddr• 11 years ago

>It made me wonder in my own professional work: should I also focus more on getting things done instead of trying to find the best solution?

As an SDET who has dealt with code perfectionist, please just focus on getting things done and features shipped. Assuming that bugs aren't life & death in your product like car software to deploy airbags, or huge consequences/delays like a land rover destine for Mars missing its mark and flying off into space. Worry about all that perfectionist stuff later, when you're sure it actually matters. Until then, as long as your code isn't a hideous abomination, it's fine. Just ship it. If you have passionate QA/SDETs, they'll find the critical bugs and do performance tests if needed. This is especially true if the product had a good spec that it was developed around.

That said, don't take any shortcuts when it comes to security!

technomancy• 11 years ago

should I also focus more on getting things done instead of trying to find the best solution?

This question can only be answered in the context of the project's life cycle. Is it in the early stages? Are there many downstream users relying on its stability? How clearly is the distinction between internals and interface communicated to downstream users? How technical are the end users?

the fact that ffmpeg has more features and its devs fix bugs and security issues more quickly seem to suggest that ffmpeg is more maintainable

Or it could just be that ffmpeg has people who are willing to dedicate a much larger amount of time to their maintainership duties. Often differences like this have much more to do with nontechnical causes like corporate support.

overgard• 11 years ago

It made me wonder in my own professional work: should I also focus more on getting things done instead of trying to find the best solution? Will that approach give better results in the end?

From personal experience: yes. The problem is the perfect solution is usually only obvious in hindsight, after you've done the work, so the quicker you get there the quicker you can get to where it "should" be.

DasIch3• 11 years ago

libav has less features and is less secure. If they can't keep up with fixing security bugs, I can't help but wonder on how they fare on less important bugs, probably not that good either.

Given how there appear to be no problems adding new features to ffmpeg, any technical debt the project has incurred seems to be within manageable range.

It doesn't look at all, as if libav is better, by any reasonable metric.

crystalgiver2• 11 years ago

The nuance in "worse is better" is that it's about the approach, not the output. libav's approach is to focus on an elegant API and software architecture instead of focusing on development speed and features.

The output in the short term is that libav is riddled with bugs, the hope is that in the long term this will pay off. Unfortunately in the interim ffmpeg seems to have propelled ahead.

zurn• 11 years ago

Except the libav idea of "better" is still unsafe.

0x09• 11 years ago

Libav on the other hand rather focuses on clean implementation and let's say better designed APIs.

This is weird to hear as a consumer of these libraries. When people ask why I prefer one or the other for my own use cases, I tell them that FFmpeg has the better API and the better format support (specifically vastly more pixel formats/depths in its lossless codecs). But regarding API, at least the parts that concern me, FFmpeg is a bit fuller and requires less boilerplate. libav* have a large surface area, so even minor affordances like avformat_alloc_output_context2 and avcodec_find_best_pix_fmt_of_list are helpful.

To be fair to Libav, due to being "downstream" FFmpeg has benefited greatly from their improvements, e.g. AVBuffer and the redone AVFrame management on top of it. They absolutely deserve credit for improving the API. But FFmpeg's API being effectively a superset of Libav, as a plain old user of the libraries it doesn't really make sense to target the latter.

That's to say nothing about the politics or people involved in the projects, it's just a matter of practicality.

jacquesm2• 11 years ago

Forking an important project like ffmpeg in a hostile manner is fraught with danger. More often than not these forks are not for technical reasons or philosophy, they're simply about ego. In a way it's like a me-too project but starting of the back of the contributers to the pre-fork one.

This kind of behavior is lethal to open source projects, end users will end up fragmented across the two versions, package maintainers for the various distros have to make tough choices and everybody loses.

Forking a project should be reserved for when a project becomes - by some objective criteria - abandoned and there is enough support for the project to continue. Then and only then should a project with a large amount of traction be forked.

Forks are both the greatest thing in the open source world and the most annoying thing at the same time, they have the potential to rescue projects but more often than not they're used to kill projects.

Really happy to see ffmpeg back, and I hope that the people that the majority of the contributors to libav switches to directly contribute to ffmpeg so that there will be an end to all the duplicated effort and wasted resources.

chei0aiV• 11 years ago

The libav fork of ffmpeg was primarily for technical reasons. Luckily those technical reasons have improved since the fork.

ank_the_elder• 11 years ago

The fork happened for human reasons (management-related) rather than technical. See http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html and http://lwn.net/Articles/423703/

kuschku2• 11 years ago

Well, no one will switch to ffmpeg – because the people who actually write most of the code you see in ffmpeg think the ffmpeg managers (admins? project leaders?) are assholes.

The whole contributor base – everyone contributing to ffmpeg – tried to get the project leader out of the project, but he refused. So these people forked ffmpeg – or rather, they took all the repos (which they owned), took all the CI servers (which they owned) and would have also taken the name ffmpeg, but the project leader owned that name.

It’s more of "one asshole vs. all the people writing the code he gives away" than anything else.

jacquesm2• 11 years ago

The whole contributor base – everyone contributing to ffmpeg

The project leader is also a contributor, so clearly not 'everyone'.

So these people forked ffmpeg – or rather, they took all the repos (which they owned), took all the CI servers (which they owned) and would have also taken the name ffmpeg, but the project leader owned that name.

There are people that consider Linus to be 'an asshole' and I'm really happy that he at least has the Linux name as a trademark.

To me, looking from the outside in and reading about the whole sage they're all assholes. You keep your dirty laundry inside and you do what you can to present a unified front to the world. As soon as you fail to do that you are failing your project in the most important sense that you can fail it: continuity.

icebraining2• 11 years ago

What about Hudson/Jenkins and OpenOffice/LibreOffice? And egcs?

I think criticizing forking is misguided; the fork is a consequence of the problem, not the cause, and it can often be the best resolution of a bad situation.

Consider what would have happened if it was impossible to fork ffmpeg: the developers who created libav would still have a problem with how ffmpeg was developed, and they could very well simply leave it. That would mean a loss to ffmpeg itself (which used the libav patches), a loss of the libav developers, and for what?

MicroBerto• 11 years ago

Would anyone be willing to provide a few commands for Ubuntu 14.04LTS that would install everything I need/want from ffmpeg and completely purge my system of libav?

Thanks!

Why Debian returned to FFmpeg

Related Stories