Linked by Brooss on Tue 15th Mar 2011 23:32 UTC
Benchmarks A comment on the recent article about the Bali release of Googles WebM tools (libvpx) claimed that one of the biggest problems facing the adoption of WebM video was the slow speed of the encoder as compared to x264. This article sets out to benchmark the encoder against x264 to see if this is indeed true and if so, how significant the speed difference really is.
Thread beginning with comment 466384
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

What he said, except I don't believe in H264-encoding DSPs which have no battery drain. There's nothing magical about DSPs, it's just a processor on the inside, eating battery power to provide computational power. The miserable battery life of current smartphones shows well enough that hardware acceleration is no panacea as far as battery life is concerned. For that, we need computational efficiency, instead of more computational power.

"No battery drain" is a myth.

Power drain was measured for the Anthill WebM hardware encoder and the results shown here:

It was measured at 12 milliwatts compared with between 1025 and 3459 milliwatts for different software releases.

Perhaps about 1% of the power drain would be a better estimate than "no power drain".

Edited 2011-03-16 11:10 UTC

Reply Parent Score: 2

Neolander Member since:

I wonder about their measurement methodology. From the title of the plot, it looks like they are comparing the power consumption of the CPU (and nothing else) between software encoding and hardware decoding.

I hope I'm wrong. Otherwise, the measurement is obviously totally flawed, as they don't take into account the power consumption of the hardware encoder itself. This plot only serves as a way to say "look, the CPU is idle and can do something else meanwhile !" (which is indeed a benefit of hardware encoders).

Edited 2011-03-16 11:31 UTC

Reply Parent Score: 1