Linked by Thom Holwerda on Fri 26th Feb 2010 13:12 UTC, submitted by poundsmack
Thread beginning with comment 411374
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
Linked by Thom Holwerda on 05/16/13 21:41 UTC
Linked by Thom Holwerda on 05/16/13 17:04 UTC
Linked by Thom Holwerda on 05/16/13 13:17 UTC
Linked by Thom Holwerda on 05/16/13 12:06 UTC
More News »
Sponsored Links



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.