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.
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.
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.
You're right but I was unaware of the fork. I installed Ubuntu 14.04 on my workstation, ran ffmpeg to do something and got a message which said:
"This program is not developed anymore and is only provided for compatibility. Use avconv instead."
Five minutes googling and I realized there had been a (somewhat acrimonious) fork. So my interpretation was quite natural: the libav developers and/or the Ubuntu maintainers were being dicks to the original project. If they really wanted to be clear they could have said something like:
"This is a deprecated wrapper around avconv, part of libav. It is not part of the ffmpeg project. See <url> for details."
"The ffmpeg program is only provided for script compatibility and will be removed
in a future release. It has been deprecated in the Libav project to allow for
incompatible command line syntax improvements in its replacement called avconv
(see Changelog for details). Please use avconv instead."
I won't take a position on this but the message you quote is a revised version that was put in place many years later after numerous user complaints about confusion.
And in my opinion it's still very confusing. If there was a more confusing version of this message and it was refined to this then I'm inclined to believe the deception was intentional.
libav is not the successor to ffmpeg. libav is a fork. How'd Debian move so quickly to a(n) (immature) fork?
That's not really true since the majority of pre-fork ffmpeg developers agreed to fork to libav.
As I say to people this is like the Catholic/Protestant split, both sides think they are the one-true-ffmpeg but both have valid claims. Doesn't change the fact it's a disastrous situation and both projects are not in particularly good states.
>both sides think they are the one-true-ffmpeg but both have valid claims.
ffmpeg is the one-true-ffmpeg. If libav surpassed ffmpeg, we'd have libav. The one-true-libav. libav doesn't have a valid claim; It's a fork second to ffmpeg.
Somebody put the cart before the horse. Happy to see it fixed.
An earlier version of the message stated that development on ffmpeg had stopped. How can you interpret this in any other way than an effort to spread FUD about ffmpeg by libav?...
This was what similar happened in our case as well. My fellow developer had convinced me that FFmpeg development was stopped libav was the successor. So, its time we need to study few more and determine what is better for a production, consumer centric application.
> 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.
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.
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.
They don't provide the same ABI (just mostly the same API), and in fact they have "so bumps" all the time, which means they break ABI compatibility with themselves all the time and need to increment the shared library major number.
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.