Having a fragmented standard or no standard at all is usually better than having a very bad one. People can always encode to multiple file types if they want to serve the increasingly large audience that doesn't support h.264.
And, BTW, Android phones just passed their iOS competitors, so, it doesn't matter how popular they will be, Android devices will be more popular. If Google decides they won't support h.264, it will be a serious hit.
I agree with your thesis. I just disagree that H264 is a worse standard than WebM.
On marketshare, while Android just passed up iPhone, something happened this past Tuesday which will probably tighten up the race a fair bit more. On top of that, the report counted iPhone subscriptions. Not iPad or iPod Touch devices. I've heard estimates that iPod Touch + iPad sales == iPhone sales.
And iPad2 is likely hitting the market in a few months.
In anycase the road we're going down is a fragmented one. Maybe people will get it right for HTML6. But I think most of the vendors at this point take the view that they'd rather have a fragmented web, rather than one dictated by their competitor.
> I just disagree that H264 is a worse standard than WebM.
Both WebM and h.264 are imperfect solutions for the same problem. WebM has a image quality issue h.264 has not, but this can be corrected, as WebM can be improved over time. The problem h.264 has - being encumbered by patents you can borrow for free only for a limited time - will not be corrected. If we decide to store all our video in h.264 we risk being unable to play it a couple years from now without paying the MPEG-LA for its licenses.
> iPod Touch + iPad sales == iPhone sales.
All it shows is that it may take more time for Android-based devices to surpass iOS's individual market share. Still, the world is not going to be an iOS monoculture. While we can't say Blu Ray is a huge success, the lack of Blu Ray drives on Apple computers cannot be credited. We consistently over-estimate Apple's influence.
> In anycase the road we're going down is a fragmented one.
I am happy for that. Diversity and competition are the twin tools of evolution. I like fast evolution.
> Maybe people will get it right for HTML6
I don't think the lack of a specification for video codec is such a bad thing for HTML5. Like I said before, the worst that can happen is HTTP header-based media retrieval of multiple encoded files. Where I work, we routinely batch-encode our video content for just about anything between classic iPods and 1080i h.264 (yes) video. Encoding for WebM will not be a heavy burden. If a pocket device asks for a URL, it gets the pocket version. If, a couple years from now, a huge 4K 3D TV asks for the same URL, it will get 4K-sized video. I think I won't have to change a single line of code...
Both WebM and h.264 are imperfect solutions for the same problem.
WebM has a image quality issue h.264 has not, but this can be corrected, as WebM can be improved over time.
Certainly it can be improved over time, but the degree of improvement will be limited to features not covered by the hundreds of video-centric patents that comprise H.264 (assuming WebM isn't already violating any of those patents). Additionally, H.264 encoding technology can be improved over time. You'd be hard pressed to make any technical analysis that demonstrates WebM could ever improve enough to exceed H.264 and it's encoding improvements. The probable reality is that H.264 will always have a not insignificant quality lead over WebM.
The problem h.264 has - being encumbered by patents you can borrow for free only for a limited time - will not be corrected. If we decide to store all our video in h.264 we risk being unable to play it a couple years from now without paying the MPEG-LA for its licenses.
That's not an accurate summation of the H.264 license. H.264 delivered for free on the web will always remain free. H.264 delivered at cost to the viewer is currently free. For more details on the cost H.264 licensing, refer to this: http://www.zdnet.com/blog/bott/by-dropping-h264-is-google-av...
So perhaps neither WebM nor H.264 are perfect ... but using the two points made to highlight the imperfections of each shows that perhaps H.264 isn't as imperfect as some would make it seem.
I'm impressed you guys encode that much. I don't think you're the common case.
The case where WebM dies is that everyone continues to encode with H264 (which is what they're doing now). If you're IE or an iOS device you get raw H264. If you're Chrome or Firefox you get H264 in Flash.
You just encode H264 and that's it. Now dual encoding, and you work everywhere.
Whereas with WebM there is NO delivery mechanism to iOS devices (iOS won't play WebM and won't play Flash). You have to dual encode to get those devices. Just seems like a less likely scenario.
> I'm impressed you guys encode that much. I don't think you're the common case.
Compared to the effort it takes to produce the content, encoding is negligible. We have a complete studio and a dedicated team producing a couple hours of original material every week. Originals are kept as uncompressed as possible storage-wise and are captured at the highest quality the equipment allows. Encoding happens in a server that's nowhere near capacity.
I proposed a presentation on it at the last FISL but it didn't make the cut (for which I am glad - two others did and it was quite enough work preparing them).
And, BTW, Android phones just passed their iOS competitors, so, it doesn't matter how popular they will be, Android devices will be more popular. If Google decides they won't support h.264, it will be a serious hit.