WebM-Enabled Browser Usage Share Exceeds H.264-Enabled ones | Hacker News Reader

WebM-Enabled Browser Usage Share Exceeds H.264-Enabled ones

hsivonen.iki.fi

94 pointsstesch55 comments

This ignores the fact that H.264 often has full hardware acceleration in the CPU or GPU of nearly all modern desktop and mobile platforms, which also covers set top streaming devices.

WebM can often use some portions of this (colorspace conversion, etc.) but until the entire stack is natively supported, there will always be battery life advantages to using H.264.

Not to knock WebM - there are projects out there to implement encode/decode in hardware (http://www.webmproject.org/hardware/ for one example) - they're just lagging about 5 years behind H.264 in this, and getting CPU/GPU vendors to dedicate space on a chip to a less codified standard will be difficult at best.

I keep hearing this battery life thing but how much battery life does H264 hardware acceleration really save? I dare to wager that the majority of the power is used by the screen, not the CPU.

According to this blog post http://blog.webmproject.org/2011/12/picking-right-driver.htm... the difference between WebM in software vs WebM in hardware is around 36%. There's also a nice graph that shows that on high brightness, the difference is smaller.

The battery savings can vary greatly depending on many hardware issues. The Nexus One, for instance, had some serious limitations.

I wrote some Android video software comparing performance of hardware and software decoders for H.264 and AAC. The Nexus One's H.264 hardware decoder used 2x more battery than a software decoder (for much less than 2x frame rate improvement). Further testing suggested that the power usage of moving video data to and from the hardware decoder outweighed any savings from overloading the CPU.

And the Nexus One's AAC hardware decoder was slower than a software decoder.

Hmm... on most desktop platforms, the decode happens in the GPU, and the flow is:

storage/network -> CPU -> GPU -> Screen

It sounds like on the Nexus One, there's some copy back into the CPU before it gets to the screen. In the version of the OS is Android doing graphics compositing in it's CPU?

I'd love to see references for this.

This ignores the fact that H.264 often has full hardware acceleration...

Yes, the rise of WebM-enabled browser market share ignores this fact.

Actually, yes.

To be more precise, the rise of WebM-enabled browser market share ignores its WebM altogether.

People use Chrome or Firefox because it's faster than IE, it has automatic update, it supports more CSS3 features (i.e. it renders more beautiful web site). I never once heard people choosing Chrome/FF over IE/Safari because of WebM.

Don't forget that all this browser still support flash with H.264 codec and most website still have flash video fallback. Hell, most website only use Flash video player.

It might just well be the article about rising maket share of Browser with green icon or some other silly factor, and statement like "Yes, the rise of green-icon browsers market share ignore this fact" would have been equally correct.

Not that it has anything to do with your parent comment missing the point of the article.

Regardless of why people choose a browser that has WebM, WebGL, or any other feature, the fact that they have that feature means that developers can start targeting it, thereby giving people more of a reason to want that feature.

Bing puts up a looped webm background every couple weeks.

Sadly in FireFox on my Macbook Air, it is pretty jittery every time it loops and sometimes during playback. They are pretty though like - http://www.bing.com/az/hprichv/?p=AntelopeCanyon_Mammoth_MHD...

Depending on how Firefox plays back H.264, it may not be using HW acceleration through the GPU. Quicktime, and recent versions of Flash have the right OS hooks in place to do this.

Sorry for nitpicking, but I don't think we should compare a container format (WebM) with a video compression format (H.264 or VP8). A container format isn't very likely to have hardware acceleration.

WebM always contains VP8 video though, otherwise it is a Matroska file.

WebM isn't a container format. It's a standard which specifies MKV (container) + VP8 (video codec) + Vorbis (audio codec).

"This ignores the fact that H.264......"

What ignores this? This article is talking about the market share of different web browsers.... What are they ignoring? I don't understand how this comment has anything to do with the article.

If comparing browsers is the purpose, then the author should not put WebM and H264 in the title.

If you consider mobile, which the article did not, the numbers are closer but still slightly favoring webm.

Opportunities for growth 4% world share of Firefox 3.6 users -> webm 26% world share of IE 6-8 users -> up for grabs? iOS/Mac growth -> mostly h.264 Android growth -> both 23% loss for h.264 if/when chrome drops support

Why webm still doesn't matter yet: demographics and fallback availability. The devices that exclusively support h.264 are more valuable users for video (mobile, console, set top box) and have no fallbacks. Most of the webm support base (desktop Firefox, chrome) can fall back to flash h.264 player. Half of the webm support base presently supports h.264 natively anyways (chrome, android)

Other notes: - webm support can be trivially added to desktop safari and IE9+ by mildly tech savvy users. - h.264 tools and encoders are better and hardware encode/decode support is far better - the openness and cheapness of webm will probably improve its tool and hardware support in the long run especially if/as uncertainty about its patent status declines.

If WebM is ready for mainstream, Google can just make it the main format for Youtube, and with a fallback to Flash. That shouldn't affect regular users at all (again, if WebM is good enough). The advantage is that by doing this, they can push WebM faster on the web, and as long as it's as good as Flash or better, there shouldn't be any drawback.

They do this already, every 10th of the Youtube videos i watch is Html5. I have testtube deactivated.

Look at the volume bar, it looks a little bit different. That i didn't recognize it most of the time is a good sign.

Just because it is HTML5 doesn't mean it's using WebM. Could be H.264 in a video tag if you're using Chrome or Safari.

Yes. Actually not only "could be", but it is H.264.

He said "Chrome or Safari" and Youtube prefers to serve WebM over H.264 where possible so it's likely WebM if it's Chrome.

It's even possible that you'll see WebM in Safari if you've got Perian installed, but I don't actually know that for a fact.

"If WebM is ready for mainstream, Google can just make it the main format for Youtube, and with a fallback to Flash. That shouldn't affect regular users at all (again, if WebM is good enough)."

AFAIK, iOS supports neither Flash nor WebM.

Using Flash as a fallback (at least currently) requires an H264 version anyway.

This only considers HTML5 <video> tag support. It does not count browsers with Flash installed as H.264-capable.

I think that’s a very important point.

The default is h.264 because Flash supports it and that used to be the only way to get video to the people. Now there are other ways, but they are not yet widespread enough, h.264 is consequently still necessary as a fallback.

Outside of Flash browsers are not terribly bad at supporting h.264 either. WebM might be doing better – but not by much. That’s the problem.

What someone who picks a video format is thinking: Many don’t have built-in support for video so we have to use Flash one way or another. h.264 is the format of choice when using Flash so we need our video in h.264. Oh, and look, that same h.264 video works in a ton of browsers without Flash. So we get kick-ass HTML5 video out of it, too, without doing any additional work. Also: iOS. WebM doesn’t even figure into this thinking and why should it? It would only complicate things for minimal gains.

For WebM to claim decisive victory it would need widespread support (I’m guessing well north of two thirds) and h.264 would have to lag very far behind. It doesn’t look like that will be happening anytime soon.

h.264 is the strong incumbent, it would take overwhelming force to take it out.

(By the way, when does WebM come to Flash again? I don’t think it is already but I think they announced it. I’m not even sure whether that will change much about the dynamic, mostly due to inertia, but I might be wrong.)

Although there was an announcement almost 2 years ago regarding VP8 support for Flash, there was no commitment made to support the Matroska container or Vorbis codec at that time, which are both part of the WebM spec.

Since then there has been no release or further communication on the topic, afaik. Looking around the web a couple months ago I found an experimental implementation of WebM decoding in Flash by Ralph Hauwert, but my understanding was that it was only able to achive 5-10 fps due to high CPU usage and no built in hardware support.

Yes. The whole point of the post is to consider <video> support.

The title is highly misleading. H.264 is the most widespread codec by far thanks to Flash. In order to show WebM has having greater "share" the article's methodology excludes enablement via Flash. So IE8 and Firefox are considered "not H.264 enabled", even though the vast majority of video viewed by them is undoubtedly H.264.

Now if you retitle it to only refer to native support for the HTML5 <video> tag that would be fair. But this still would have little impact on video codec choice. You want a codec that is widely supported and hardware accelerated, ideally. H.264 fits that bill through a combination of native HTML5 and fill-in Flash support, and that's exactly the best practice for video on the web today.

While this is an interesting snapshot of the state of HTML5 video support today, we should keep in mind that not all formats give the same results and that many browsers support multiple formats. Which percentage figure is higher in that table doesn't help to make many useful decisions.

For example, in testing for a new video-based service, we're finding that H.264 gets similar quality with about half the bit-rate of Theora. The MP4 files therefore come out about half the size of the OGVs. That is very significant for bandwidth that the host is paying for, and for people using mobile devices, who typically have much lower data caps in their prepaid plans than a landline broadband connection.

Another consideration is the processing to create the videos in the first place. We do lots of fairly basic video manipulation using automated tools within our workflow, processing lots of video files on not a lot of hardware. H.264 is noticeably faster than all other formats for all of the manipulations we have benchmarked so far, and usually Theora is in last place again. That means supporting H.264 vs. supporting H.264+Theora is a days vs. weeks issue every time we process a new set of videos.

I do appreciate the desire to use more open/royalty-free formats as a general principle. However, until something like WebM/VP8 catches up in terms of compression/quality and just as importantly in terms of performance and availability of tools, I don't see H.264 going anywhere. Browsers that support it will give their users a better experience, and browsers that won't or can't support it will be at a disadvantage.

Why are you comparing to Theora rather than webm/vp8?

Because the tools to manipulate WebM/VP8 don't seem to be as mature yet. It still requires significant hassle to keep FFMPEG-based tools up to date, for example.

I believe google still hasn't pulled h264 support from chrome despite announcing they would do so quite a few versions back.

As OpenCL support picks up, including in the embedded space, hardware acceleration for WebM may be a possibility in the future. It's possible GPU manufacturers will eventually drop native H.264 support & go for a "software based" OpenCL solution. Obviously not going to happen overnight, but OpenCL is already available in something like the PowerVR SGX543MP.

AFAIK OpenCL isn't good for video decoding.

AFAIK OpenCL isn't really good for "anything" as of right now. There is really nothing practical that uses OpenCL out yet. I'd give it 5 years & then we'll see where we're at. Later versions of OpenCL might even contain video decoding specific extensions that are hardware agnostic.

What would make OpenCL worse for video decoding than for example, C? If anything it would be better, since it has `native' support for certain vector operations and parallel processing.

It's not and never will be, because it's the wrong level of abstraction. For power efficiency you need an ASIC or something close to it. If you just want to be fast, ffvp8 is fine.

The big thing this article glosses over is ie8. It's counted as No Video, but over the next year the direction they go will tell the story as it is the browser with largest share but no builtin video support

I'm guessing that when Chrome added WebRTC last week (http://www.webrtc.org/blog/webrtcnowavailableinthechromedevc...} they only added VP8 encoding, so when Firefox adds it the numbers will skew even stronger toward WebM for native encoding.

Does this count Chrome as not supporting h.264? As far as I know it still does.

I'm having a hard time believing chrome+safari+ie < chrome+firefox+opera I guess it is a smaller percentage of IE that supports <video> than firefox?

Does anyone else find these numbers off?

They answer the question about Chrome in the FAQ at the end now:

"You Are Counting Chrome as Supporting H.264 Even Though They Dropped Support!

In January 2011, they announced that H.264 support would be dropped. As of January 2012, Chrome has not yet dropped support for H.264."

Regarding the figures, they look anomalous until you realise that IE8 and older don't support HTML5 video at all, and that the figures for browsers that do have a lot of overlap because most recent browsers support multiple video formats. Since H.264 via Flash is excluded, so are older IE browsers, and IE9 has a much smaller market share than IE as a whole, which explains why the side with Firefox on it works out a bit bigger than the side with IE on it in your comparison there.

Yes, it counts Chrome as supporting H.264.

Only IE9 and above support <video>, so the share of IE8 and older doesn't count as H.264 share. Firefox 9 has a larger usage share than IE9.

(I included the script so that people could read it to see what was counted instead of speculating...)

Now we just need a faster WebM encoder. libvpx is always slower than x264, even up to 2 times slower.

I have HTML5 enabled in Youtube, yet I still cannot watch most of the videos because they are served as Flash only. So why is Google pushing Webm when their top video site does not make use of it?

Two things:

a) this doesn't include mobile/tablet browsers, thus it's irrelavent.

b) this is only the case because Google deliberately dropped support for a recognised format backed by open standards, in exchange for an arguably inferior format that it just happens to own.

"Open standard" is a vague term. To many people, open doesn't mean "as long as you have a license". Google purchased On2 specifically to release WebM, not "just happens to own".

I was making light of Google's Microsoft-ish tactics: Buy tech. Release for free Try to convince people its better than an existing open standard.

Please point out a case when Microsoft purchased a company and released their proprietary product with a FLOSS license and a patent grant.

He said open standard, not FLOSS.

Confirming that it's not a Microsoft-ish tactic.

a) Most web videos play through the native app on mobile, don't they?

b) WebM is not a proprietary format

What native app? Regardless, how many mobile devices support WebM? And how many of them are hardware accelerated?

Android 2.3+ supports webm via the video tag. I am not sure what the hardware acceleration status is, certainly not as good as the near ubiquitous hardware h.264 support.

In response to (a), the article says "In other words, the non-desktop browsers that StatCounter reports in its desktop stats account for less than 3% of usage." According to the stats, WebM-supporting browsers have about a 5% market-share lead over H.264-supporting browsers, so even if all of that 3% support H.264 video (and I suspect that many of them don't support <video> at all), WebM-supporting browsers would still have a 2% lead.

Sure, desktop browsers aren't the trendy thing any more, and there's more PR value in having your website work on the iPad than market-share numbers would suggest, but for people not concerned with PR (say, hobbyists, rather than startups), this is a useful number to know.

In response to (b), also because Mozilla deliberately avoided support for a recognised format, in exchange for an arguably inferior format that Google happens to own. Which is to say, I'm not sure why that particular observation is relevant — however we came to be here, it's interesting to know what the current state of play is.

> In other words, the non-desktop browsers that StatCounter reports in its desktop stats account for less than 3% of usage

Then their stats are not realistic.

Reply on news.ycombinator.com