Linked by Thom Holwerda on Fri 26th Feb 2010 13:12 UTC, submitted by poundsmack
Multimedia, AV The debate about HTML5 video is for the most part pretty straightforward: we all want HTML5 video, and we all recognise it's a better approach than Flash for online video. However, there's one thing we just can't seem to agree on: the codec. A number of benchmarks have been conducted recently, and they highlight the complexity of video encoding: they go either way.
Thread beginning with comment 411233
To read all comments associated with this story, please click here.
Blind test?
by stanbr on Fri 26th Feb 2010 19:49 UTC
stanbr
Member since:
2009-05-22

I think a blind test would be really cool. A bunch of videos using both encodeing head to head (at random location of the screen) and the user should pick witch one he thinks looks best. Check the results and you will have a fair winner. Of course the enconding should be done at the same conditions.

Reply Score: 2

RE: Blind test?
by mckill on Fri 26th Feb 2010 19:57 in reply to "Blind test?"
mckill Member since:
2007-06-12

well except one of them will need a desktop or high end laptop to play while the other can be hardware decoded on just about anything.

Reply Parent Score: 3

RE[2]: Blind test?
by darknexus on Fri 26th Feb 2010 20:47 in reply to "RE: Blind test?"
darknexus Member since:
2008-07-15

Hardware will inevitably follow the demand. If a codec were mandated for HTML 5 and everyone began to use HTML 5 video, you can bet the hw companies would start producing hardware accelerator chips for that codec. To do otherwise would just be a bad business decision. We have a lot of h.264 hardware right now because that's where the trend was at the time, if the trend shifts the hardware will shift along with it. Remember when most devices expected Mpeg 4/DivX?

Reply Parent Score: 2

RE[2]: Blind test?
by pgeorgi on Sat 27th Feb 2010 15:23 in reply to "RE: Blind test?"
pgeorgi Member since:
2010-02-18

The ARM SoCs I work with have a codec accelerator subsystem. It's basically a coprocessor that you initialize with some opaque piece of (non-ARM) code, which does h.263, h.264 and VC1 decoding and encoding (to various degrees).

The total size of this driver (that you upload) is about 80KB, so I guess they'd have the space to add another codec in there (given that address spaces are usually in powers-of-two).

Once there's a demand, this coprocessor will gain an updated firmware (that is uploaded on boot), and supports whatever codec the demand is for.

I just looked for a number of ARM codec support options, and all I found are advertized with "Upgradeable with new codecs" and similar statements.

With that in mind, "hardware acceleration" is a non-issue for new contenders in video.
Other than with MP3 players which actually used special MP3 decoding chips, video decoding is too complex to be done "in silicon" - I'd guess it's always software.

Reply Parent Score: 1