
WebM-Enabled Browser Usage Share Exceeds H.264-Enabled ones - stesch
http://hsivonen.iki.fi/webm-share/
======
zdw
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.

~~~
asomiv
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.

~~~
cpeterso
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.

~~~
zdw
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.

------
zaphoyd
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.

~~~
nextparadigms
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.

~~~
Someone
_"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.

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

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

~~~
ugh
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.)

~~~
aethr
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.

------
abalone
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.

------
Chris_Newton
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.

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

~~~
Chris_Newton
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.

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

------
Klinky
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.

~~~
wmf
AFAIK OpenCL isn't good for video decoding.

~~~
Klinky
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.

------
kenjackson
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

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

------
RandallBrown
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?

~~~
hsivonen
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...)

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

------
av500
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?

------
stephenr
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.

~~~
dchest
"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".

~~~
stephenr
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.

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

~~~
mikemaccana
He said open standard, not FLOSS.

~~~
dchest
Confirming that it's _not_ a Microsoft-ish tactic.

