Not to pull attention away from this post, but if anyone is curious about the Flash renderer I wrote (the one mentioned in the article), I've released the source: http://github.com/daeken/Arienette
In retrospect, I should've stuck with it; I knew that Adobe's iPhone code would be delayed as hell, but didn't think there'd be enough lead time to make my money's worth off of it. If I would've known they were going to delay it this heavily, I could've had a product out and making money already. Hindsight is 20/20, I guess.
It also depends on what [Google's] target is: would try to push hardware support too?
A while back there was an IamA on reddit from a video codec hardware engineer. I found this comment interesting:
We've been asked to support ON2's VP6 and possibly other codecs. Google isn't done entering the video market, and this is part of that push. I can't really divulge anything more sorry.
One of the Mozilla guys pointed to a schematic for the new low cost Marvell Armada ARM chipset (the one advertised as bringing a new generation of $100 dollar Android phones) and it had On2 listed in the decoding section.
I can't find the link because twitter search sucks and the Marvell site all seems to consist entirely of Flash and PDFs.
This is probably the best analysis of the VP8 situation I've read. One takeaway: if Google wants to make VP8 ubiquitous on the web, it probably could (by leveraging YouTube), but that wouldn't kill H.264. It would more likely set up two competing codecs, which would be good for everyone except the patent holders.
It wouldn't be good for YouTube or other video sharing sites. There are two (well, two that don't require Flash) competing video codecs now-- it's expense that keeps them from both being utilized. Like the article says storage is the mitigating factor to adoption by the video sharing companies.
Depends if both codecs need to be implemented by every site. If Flash or HTML 5 supported both, content owners would be able to choose one or the other.
I have a hard time believing that VP8 would have any effect on HTML5 video:
- So far as I know, Apple and Nokia refused to support Theora because they were already heavily invested in H.264, and they didn't want to open themselves to more patent risk than they already had. These reasons apply equally well to VP8.
- Mozilla picked Theora because it was the most production-ready patent-free codec. Even if VP8 had zero patent risk, libtheora is already written and tested and portable.
There's been huge buzz among Mozilla, FSF, and so forth about the Google purchase of On2 and VP8. They're all basically pleading for VP8 to come out in order to replace Theora. It was really sudden, just over the past few days.
Even if VP8 had zero patent risk, libtheora is already written and tested and portable.
There are things that matter more than just being tested and portable, like whether it's actually good.
It hasn't exactly been sudden; people have been asking if Google has been planning this ever since Google announced it's intent to acquire On2. See http://www.theregister.co.uk/2009/08/06/google_vp6_open_sour... for example. The buzz picked back up again once Google finalized the deal; they spent a while in negotiation.
One of the barriers to adoption of Theora has been the quality issue; why would Apple or Nokia take the extra risk and cost of going with Theora if they already implement a superior codec? There's a chance that VP8 would help with that, but it's still an uphill battle. It took years for Xiph to take VP3 to something that they wanted to call a stable standard. Google has more resources than Xiph, for sure, but they likely can't just dump VP8 as-is as a new standard. There's also the issue of submarine patents, the hardware issue, just getting this implemented and as widely deployed as H.264, and more, so yeah, it would be tough for this to become a standard.
On the other hand, what the heck else is Google planning on doing with On2? Why would they get into the proprietary codec business, when H.264 seems to be winning out in most places in the market, and they've already bought all the licenses, encoded most of YouTube in H.264, and so on? Of course, those questions also apply to an open codec, but Google has been a big proponent of open, freely implementable standards, so at least that route makes some amount of sense.
Yes, why would MPEG patent holders Apple and Nokia refuse to implement a competing video codec? It's a mystery wrapped in an enigma.
But I fully believe them when they say it's patent risk. Just like I believed Nokia when they said it was because Theora was "proprietary" and that it was impossible to implement DRM with Theora.
In that position paper you can see that Nokia is really keen to push MPEG towards patent-free licencing, but their big strategy to achieve this is to lock themselves into MPEG. Not very smart, but maybe Google can get some momentum going in that direction.
(Related fact: Nokia also argued for Software Patents in Europe.)
Didn't the Gnash folks set themselves up for epic freetard failure by refusing contributions from anyone who's ever installed Flash?: http://www.gnashdev.org/?q=node/25#eula
Winning or losing in court isn't what matters -- the cost of defending oneself in court is enough to "enforce" any bogus contract or license provision against a significantly smaller opponent, such as a lone open source developer.
Adobe’s H.264 encoder in Flash Media Encoder is so utterly awful that it is far worse than ffmpeg’s H.263 or Theora; they’re practically assuming users will go use x264 instead.
Why is x264 GPL licensed instead of LGPL like FFmpeg? It would make x264 the de facto H.264 encoder.
It already is the de facto for many situations--but for the reason you mentioned--primarily only on server-side apps.
The GPL is used for historical reasons; relicensing would be hard, obviously, because we have to contact everyone who ever wrote a line of code. Ironically we are doing that right now, but for a dual-license scheme (GPL/Proprietary).
The reason we didn't choose LGPL for the relicense is because one of the main devs (not me) refused; he saw releasing the source as LGPL to be effectively throwing away any chance to ever make any money off of his work, while keeping the code as GPL would at least reserve that option for the future. The dual license is a good compromise IMO; commercial applications can support development through license fees while free software gets to use it for no cost.
Slightly amused by the engineer worldview evident in the last line.
"psy optimizations are the single most critical feature ... they're the reason that Vorbis beat MP3 for audio"
So in other words, they're not the most critical feature since Vorbis quality and freedom didn't budge MP3 and so, if we imagine a parallel world where x264 does not exist and Google's VP8 was actually noticeably better than the best H.264 (like Vorbis vs MP3 or on par like Vorbis vs AAC) we would find that anti-competitive patent pools would still be forcing us to use their choice of codec.
The best we can reasonably hope for, as we saw with Vorbis, is for a strong competitor to prevent crazy licence fees. And maybe in time for H.265 the EU or China will have enough political clout and common-sense to demand that international video standards must be royalty free.
In retrospect, I should've stuck with it; I knew that Adobe's iPhone code would be delayed as hell, but didn't think there'd be enough lead time to make my money's worth off of it. If I would've known they were going to delay it this heavily, I could've had a product out and making money already. Hindsight is 20/20, I guess.