this seems a clever move, but as I understand it it's something for content providers, not users. As such, it would appear issues from content consumers such as mozilla still stand, or am I misunderstanding?
Mozilla is still on the hook for £5 million a year (and rising) to provide H.264 in their own binaries, but that right doesn't cascade to open source derivatives, if they decide to stop fighting for web standards that meet the W3C definition.
It's interesting that these victories are often viewed as defeats for the technologies that forced their competitors hands and saved consumers large amounts of money.
They'll stick with their jackass NIH attitude and continue to link directly with liboggplay and libwebm.
You're the jackass for not implementing this. Open Source is not a bureaucracy where you do whatever your boss tells you to do. You do stuff because you want to. The current set of Firefox developers doesn't want to support H.264. You do. You both have the same source code and the same number of hours in a day. So add it yourself.
If people want to, they will use your version instead of Firefox. Remember Netscape? Neither do I...
So it comes down purely to the maintenance burden — but the codebase was organized so that I'd need hostile forks of Gecko, XULRunner, and Firefox. No thanks. Shortly afterward Chrome was usable on Linux, and I no longer had an itch to scratch.
http://www.bluishcoder.co.nz/2008/04/firefox-html5-video-wit...
Once it was decided to not use GStreamer for the desktop we continued with the work on the Ogg backend and the patch bitrotted. It was subsequently picked up by another Mozilla developer for Fennec work. The patch is currently waiting on review (by me) and as I understand it it will be landed but disabled at compile time for third parties to enable if they want it. I'm not involved in that decision or whether it would be in desktop Firefox however.
An H.264 specific backend wouldn't be too hard to do. It should only be a few days work to get a ffmpeg backend going for H.264 support. I had a partial one implemented that I used for testing although it has bitrot quite a bit now.
Your point about having to maintain a fork still stands however as there's no pluggable API for backends.
The WebM support is implementing using libvpx (Google's VP8 reference decoder library), libnestegg (a WebM container library), and libvorbis.
They're all still builtin however so this doesn't do anything to change your NIH assertion.
Why make up fake reasons for them to not adopt it when they're very clear it's a licencing issue.
If you're running a transcoder (Zencoder, Quicktime Pro, ffmpeg) or a player (Flash, native HTML5 video in Firefox), you still may need to pay royalties.