Hacker News Reader

Comment by zimbatm | Hacker News Reader

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.

View on HN

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.

I always thought the message was intentionally confusing.

It was untrue. It was a fork and they acted like ffmpeg was no longer being developed. To me this was a horrible way to fork something.

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.

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?...

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."

How hard would that have been?

>How hard would that have been?

Probably pretty rough on the ego.

This. Ubuntu was the main reason why people assumed ffmpeg became deprecated, in other words libav just got more vocal PR/support.

Gentoo initially followed the mainstream but changed the default flag to ffmpeg a few months ago.

It's something in between.

"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?

Politics.

No, it moved because the forkers were also the Debian package maintainers.

Basically it was a big split down the middle, the entire project split in half.

Which makes Debian's return to FFmpeg all the more noteworthy.

So it was political, like I said.

Not to kick 'em while they're down but it certainly wasn't on technical merit.

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.

14.04 broke a previously working build because of this. I spent way more time than needed trying to debug it because of this cryptic bullshit.

> 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.

> The Debian security team vetoed this option

On what grounds?

The high frequency of security issues in both packages makes it a significant burden to support both of them simultaneously: https://lists.debian.org/debian-devel/2014/02/msg00668.html

There appear to also be issues with frequent soname bumps: https://lists.debian.org/debian-devel/2014/02/msg00651.html

This is answered in the article this post is about.

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.

contrib is not for unsupported packages. It is for free software that depends on non-free software.

> 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.

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.

> 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.

Reply on news.ycombinator.com