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