7 ms·

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

94 points by stesch 15y ago

ZeroGravitas 15y ago
I'm guessing that when Chrome added WebRTC last week (http://www.webrtc.org/blog/webrtcnowavailableinthechromedevchannel 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.
stephenr 15y ago
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 15y ago
  "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 15y ago
    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 15y ago
      Please point out a case when Microsoft purchased a company and released their proprietary product with a FLOSS license and a patent grant.
      - mikemaccana 15y ago
        He said open standard, not FLOSS.
        dchest 15y ago
        Confirming that it's not a Microsoft-ish tactic.
- nextparadigms 15y ago
  a) Most web videos play through the native app on mobile, don't they? b) WebM is not a proprietary format
  - stephenr 15y ago
    What native app? Regardless, how many mobile devices support WebM? And how many of them are hardware accelerated?
    - zaphoyd 15y ago
      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.
- thristian 15y ago
  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.
  - stephenr 15y ago
    > 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.
andrewf 15y ago
This only considers HTML5 <video> tag support. It does not count browsers with Flash installed as H.264-capable.
- ugh 15y ago
  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 15y ago
    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.
- hsivonen 15y ago
  Yes. The whole point of the post is to consider <video> support.
zaphoyd 15y ago
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 15y ago
  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.
  - sek 15y ago
    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.
    - stanleydrew 15y ago
      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.
sfgfdhgfdshdhhd 15y ago
Chrome doesn't support H.264 yet this guy counts it among the H.264 capable browsers. WebM: Chrome, Opera and Firefox. 50% worldwide share H.264: IE9 and Safari. 15% worldwide share
av500 15y ago
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?
zdw 15y ago
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/ 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 15y ago
  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.
  - dchest 15y ago
    According to this blog post http://blog.webmproject.org/2011/12/picking-right-driver.html 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.
  - cpeterso 15y ago
    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.
    - 15y ago
bradleyjg 15y ago
I believe google still hasn't pulled h264 support from chrome despite announcing they would do so quite a few versions back.
Klinky 15y ago
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 15y ago
  AFAIK OpenCL isn't good for video decoding.
  - astrange 15y ago
    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.
  - Klinky 15y ago
    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.
  - jensnockert 15y ago
    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.
RandallBrown 15y ago
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?
- deleted 15y ago
  [deleted]
- Chris_Newton 15y ago
  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.
- hsivonen 15y ago
  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 15y ago
Now we just need a faster WebM encoder. libvpx is always slower than x264, even up to 2 times slower.
Chris_Newton 15y ago
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 15y ago
  Why are you comparing to Theora rather than webm/vp8?
  - Chris_Newton 15y ago
    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.
kenjackson 15y ago
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
kenjackson 15y ago
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
abalone 15y ago
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.

94 points by stesch 15y ago

I'm guessing that when Chrome added WebRTC last week (http://www.webrtc.org/blog/webrtcnowavailableinthechromedevchannel 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.

stephenr 15y ago

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 15y ago
"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 15y ago
  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 15y ago
    Please point out a case when Microsoft purchased a company and released their proprietary product with a FLOSS license and a patent grant.
    - mikemaccana 15y ago
      He said open standard, not FLOSS.
      - dchest 15y ago
        Confirming that it's not a Microsoft-ish tactic.
nextparadigms 15y ago
a) Most web videos play through the native app on mobile, don't they? b) WebM is not a proprietary format
- stephenr 15y ago
  What native app? Regardless, how many mobile devices support WebM? And how many of them are hardware accelerated?
  - zaphoyd 15y ago
    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.
thristian 15y ago
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.
- stephenr 15y ago
  > 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.

andrewf 15y ago

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

ugh 15y ago
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 15y ago
  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.
hsivonen 15y ago
Yes. The whole point of the post is to consider <video> support.

zaphoyd 15y ago

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 15y ago
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.
- sek 15y ago
  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.
  - stanleydrew 15y ago
    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.

sfgfdhgfdshdhhd 15y ago

Chrome doesn't support H.264 yet this guy counts it among the H.264 capable browsers. WebM: Chrome, Opera and Firefox. 50% worldwide share H.264: IE9 and Safari. 15% worldwide share

av500 15y ago

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?

zdw 15y ago

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/ 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 15y ago
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.
- dchest 15y ago
  According to this blog post http://blog.webmproject.org/2011/12/picking-right-driver.html 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.
- cpeterso 15y ago
  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.
  - 15y ago

bradleyjg 15y ago

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

Klinky 15y ago

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 15y ago
AFAIK OpenCL isn't good for video decoding.
- astrange 15y ago
  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.
- Klinky 15y ago
  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.
- jensnockert 15y ago
  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.

RandallBrown 15y ago

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?

deleted 15y ago
[deleted]
Chris_Newton 15y ago
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.
hsivonen 15y ago
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 15y ago

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

Chris_Newton 15y ago

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 15y ago
Why are you comparing to Theora rather than webm/vp8?
- Chris_Newton 15y ago
  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.

kenjackson 15y ago

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

kenjackson 15y ago

abalone 15y ago

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.