Hacker News Reader

Comment by TomOfTTB | Hacker News Reader

If Google really wants to force WebM adoption they need to go "all-in". Set a deadline for pulling all h.264 videos from YouTube and force Apple and Microsoft to support the WebM standard.

I know that sounds worse than what they're doing but hear me out. Right now they're creating an environment where everyone will have to do twice the work to support HTML5. That's not good for anyone.

So if they're insistent on making WebM the standard they need to pull out the big guns and force Apple and Microsoft to capitulate. It'll be bitter and nasty but at the end we'll get a standard out of it and not a fragmented mess.

View on HN

This "twice the work" argument was clearly addressed by the post. Firefox has a much larger market share than Chrome and has already clearly stated they will not support h.264. If anyone created a problem of having to do "twice the work" it was Firefox and Google has just decided to support them in it.

And using their position as owner of YouTube to force h.264 out before WebM is ready would just hurt YouTube and make everyone with a mobile device made prior to WebM decoders being included (assuming that gains momentum) unable to watch YouTube videos.

The twice the work wasn't really addressed. No one really cares about the desktop. You can get whatever codec you need whenever. It's mobile that people care about. That's where HTML5 will really make a difference. Firefox is nowhere in Mobile.

If this was just about the desktop I'd say just randomly encode every video. I'm going to have every codec installed anyways. But that's not the discussion.

> No one really cares about the desktop.

Last time I checked desktop usage was still is 90-99% range, 3G bandwidth — even with H.264 — allowed only low-quality video streaming, and operators were tightening limits on their "Unlimited†" tariffs.

If you really care about mobiles today, you're encoding special mobile-only (low-res baseline profile) version anyway. Codec war on desktop doesn't really affect that yet.

No one cares about the desktop, not because of popularity today, but because of popularity tomorrow. And more importantly is the other point I made. On my desktop I have ever codec ever created. It doesn't matter what <video> uses. But it's all of my mobile (and embedded) devices that don't have support for every codec, and I generally can't install a new codec on them.

To put it another, if there were no mobile devices, this would be a complete non-issue.

No one cares about H.264 via HTML5, not because of popularity today, but because of popularity tomorrow.

Devices with the fastest growing mobile OS and hardware WebM decode are shipping this month (they also support H.264 and legacy VP6 via Flash). The hardware churn rate in mobile will solve this problem rapidly and the gaps can be filled quite easily by software wherever there is a will.

Devices with the fastest growing mobile OS and hardware WebM decode are shipping this month

That doesn't make any sense. What you meant to say was that the fastest growing segment of mobile devices, prior to the iPhone/Verizon, is Android with devices that don't have WebM HW acceleration.

Again, I'm fine with a fragmented HTML5 world. There will be the Google WebM world. And the MS/Apple H264 world. I'm perfectly happy with that.

So you care only about tomorrow's popularity, but are worried about today's hardware?

Tomorrow decoding of WebM on mobiles might not be a problem, even for battery life. Mutlicore SIMD and programmable GPUs are coming already, and their power efficiency steadily increases.

Google has got Qualcomm, Broadcom and few others on board with WebM. If WebM takes off, Apple will need to take all their chipset production in house in order to get chipset without WebM acceleration ;)

Did you miss where I say, "And more importantly..."?

And which chips are on the roadmap to have WebM support? I don't know of any announced QCOM or NVidia devices that have WebM support. The only I've seen is Broadcoms, and its certainly not on par with the existing H264 HW accelerators.

And if Intel doesn't add WebM support, which I don't believe they have commited to doing, this could be long haul. Because desktop isn't sufficient with respect to codecs, you do need desktop chipset support with respect to acceleration. No one will be happy if they can't watch 720P video on their high end computer.

Best case scenario is that we see WebM having the level of coverage as H264 has TODAY is probably 2013.

Like I've said, there will be those of that fight against WebM and you'll fight for it. Maybe we just end up with a fragmented world.

If they were to force H.264 out they'd clearly have to make an exception for devices that were not capable of playing WebM. To think otherwise would be idiotic (and is an obnoxious straw man argument on your part). But that's not hard to do.

So that doesn't invalidate my point which is they should either REALLY force the issue or drop it. Right now they're making a half hearted effort that guarantees fragmentation.

(As for your first point I agree with the other reply)

> If anyone created a problem of having to do "twice the work" it was Firefox...

Huh? As I understand it, H.264 was never an option for Firefox due to the patent encumbrance and licensing fees they would incur for distributing it.

The people who chose to use H.264, despite knowing that the second most popular browser wouldn't support it, made twice the work for themselves.

Not really; by choosing H.264 they chose only one format to keep their videos in, and relied on Flash to offer it to the desktop browsers refusing to support H.264 natively.

There were three options.

One was to build in explicit support for h.264 in Firefox and for Mozilla to pay the MPEG-LA ~$5million/year in licensing fees.

Another was to punt to the operating system and let gstreamer/directmedia/quicktime do the decode. Even though it would have been without cost to them, Mozilla chose not to do this as part of their moral stand against h.264. This was why they were so sharply criticized.

The third option was to let the Firefox Flash plugin do the decoding, which is what we have today.

Exactly. Removing support for h.264 + the VIDEO tag from Chrome will accomplish nothing more than what Firefox accomplished a year ago when they said that they wouldn't support h.264 in the first place. A year later and no one is serving Theora over the VIDEO tag - instead there are just a lot of Firefox users viewing h.264 in FLV containers in Flash. Chrome's stand against h.264 will convince precisely 0 (ZERO) video websites to double their CPU budget by double-encoding to h.264 AND VP8.

It's what Google does with Youtube that could really change something. If they stop serving h.264 from Youtube, then we'll all be switching to WebM/VP8.

Or release a WebM playback enabler which is more sensible and as effective:

The WebM Project team will soon release plugins that enable WebM support in Safari and IE9

so we're back to plugins, what was the point of the <video> tag again?

as mentioned in the post, since firefox is 25%+ of the market and will never budge, it was alway going to have to be webm or plugins.

no one (hopefully) wanted this situation, but the reality is that the different parties involved disagree strongly about what codec should be the defacto standard.

Because Apple and Microsoft are able to obsolete these plugins if they choose so (I'm not saying it's the best solution, but it's legally and technically feasible), and others don't require those plugins.

It's not that easy the other way, where you've got closed reference implementation of Flash (and you can't get it without plugin) and there are patent royalty payments for H.264 decoders.

Because the plugins in question are for the operating system's video infrastructure (Quicktime and DirectShow), not the browser.

<video> still acts as a standard platform API across browsers regardless of codec support. It's not like the bad old days where you would have your page manually loading opaque QT or WM or Real plugins through <object> and <embed>.

Reply on news.ycombinator.com