I don't think the decision was as obvious from the beginning as you're suggesting. Today, it seems rather obvious that ffmpeg has a much higher development rate. When the fork first happened, libav got a pile of development that made it appear much more active than ffmpeg.
With 20/20 hindsight, sure, Debian should have gone with ffmpeg. But that was not obvious at the time. From the outside, the ffmpeg/libav split looked a lot like the XFree86/Xorg split, where the people doing the work and the people with commit access were too disjoint.
It's also not at all obvious why the libav developers would choose to ignore the work on ffmpeg, while the ffmpeg developers have pulled in changes from libav. From the outside, that decision seems crazy.
There's also the fact that pre-fork FFmpeg was incredibly dysfunctional. I fully expected Libav to pull ahead very quickly due to that there were a lot of real problems with how FFmpeg operated. However, post-fork FFmpeg ended up also mostly resolving those problems (both because there were fewer developers involved that refused to work together, and because MiNi started doing a much better job as maintainer), which I don't think anyone expected.
> It's also not at all obvious why the libav developers would choose to ignore the work on ffmpeg
They have pulled in some things from FFmpeg, but avoiding having to work with some of the FFmpeg developers was one of the main points of the fork. Pulling in all of Libav's changes has been a continual source of pain for FFmpeg and they've talked about halting it a few times, but it is ultimately the reason why FFmpeg is so far ahead in features now.
It was crystal clear within 6 months of the fork. Additionally, the fork itself was an attempted hostile takeover - with git "push -f" (or equivalently, pointing to a different server with a different history), and other lousy stuff. If you were following development weekly, it became clear within 3 months or so.
The main reason debian (and hence ubuntu) packaged libav instead of ffmpeg is that one of the libav guys is also a debian guy.
The libav guys apparently had genuine criticism about ffmpeg development that they felt were not addressed within the prevailing ffmpeg development model at the time -- and thus they had to fork. For all I know, (as an involved user), they were completely right, and perhaps ffmpeg would not have been as good as it is today had they not forked.
However, neidermeyer et al seemed to have responded to the fork with a significantly improved development process. before libav, ffmpeg improved slowly, and tended to reject contributions. Since libav, ffmpeg is improving rapidly, and when code is contributed, they bring it to their standard rather than rejecting it for not living up to it.
Yeah, I agree with this. I think when I posted this I was fairly caught up in my ongoing frustration with this issue. That being said, I'm a developer in my 20s. I wasn't around when a lot of this was actually happening. For the most part, I've relived it through mailing lists and blog posts over the 3ish years I've been an avid user of ffmpeg. I think that tends to skew my historical perspective unfairly. In other words, the perspective and history is very much appreciated.
With 20/20 hindsight, sure, Debian should have gone with ffmpeg. But that was not obvious at the time. From the outside, the ffmpeg/libav split looked a lot like the XFree86/Xorg split, where the people doing the work and the people with commit access were too disjoint.
It's also not at all obvious why the libav developers would choose to ignore the work on ffmpeg, while the ffmpeg developers have pulled in changes from libav. From the outside, that decision seems crazy.