Yes, the rise of WebM-enabled browser market share ignores this fact.
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.
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.
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.
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...
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.
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.