WebM, H264: Encoder Speed Benchmark
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.
E-mail Print r 2   71 Comment(s) http://osne.ws/ixc
Thread beginning with comment 466372
To view parent comment, click here.
To read all comments associated with this story, please click here.
Neolander
Member since:
2010-03-08

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.

Reply Parent Score: 2

tuzor Member since:
2007-08-07

The miserable battery life of smartphones is mostly due to the power consumption of antennas in the device and your distance from the source.

Turn off 3g and you'll see the difference.

Reply Parent Score: 1

Neolander Member since:
2010-03-08

Then why do Symbian phones typically last much more than Android/iOS ones on battery, even at similar connectivity settings ?

The screen does have a role to play, but twice the screen area does not explain a 1.5 day vs 4.5 days difference alone. Software also has a role to play there.

Reply Parent Score: 1

Neolander Member since:
2010-03-08

Then why do Symbian phones typically last much more than Android/iOS ones on battery, even at similar connectivity settings ?

The screen does have a role to play, but twice the screen area does not explain a 1.5 day vs 4.5 days difference alone. Software also has a role to play there. Faster, more modern hardware consumes more power when it runs at full speed, but theoretically less power when running at low speed...

Reply Parent Score: 2

lemur2 Member since:
2007-02-17

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:
http://blog.webmproject.org/2011/03/introducing-anthill-first-vp8-h...

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:
2010-03-08

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

konfoo Member since:
2006-01-02

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.


You must be new to this and/or forgotten the whole H264 debacle over mobile SoC hardware decode/encode from ~ 2001, which is now repeating itself, once again.

Here, note where it says 'battery savings':

http://news.cnet.com/8301-30685_3-20043249-264.html

Reply Parent Score: 1