Licensing isn't the (only) issue for asics. Hardware decoders are only reasonably priced if they're being produced at scale. If I'm a device manufacturer and I have a choice between getting h.264 for free because it's on the SoC I'm using and paying multiple dollars (!) for a WebM decoder, not to mention wasting valuable board space and paying for it to be soldered on, which do you think I'll choose?

1) You aren't going to get H.264 decoder for free. There will be always at least license fees to MPEG-LA. 2) Current hardware video decoders are DSPs. You are not going to "waste valuable board space". It is a program in ROM, it is easy to change H.264 to VP8, you will probably even save some space.

1) Those license fees approach zero as you produce more units.

2) If I'm not mistaken they're not general purpose computers. If they were what would be the point? Why not use a math coprocessor?

Most hardware video decoders are special-purpose DSPs that the manufacturers write firmware/microcode for to decode particular formats. The instruction sets of the DSPs are well suited to operations normally performed when decoding (or encoding) video.

> If I'm not mistaken they're not general purpose computers. If they were what would be the point? Why not use a math coprocessor?

They are not general-purpose, but that doesn't mean they're not easily re-programmable either. Consider the example of GPUs.

I want to say some SNES games used a DSP chip, there are several known to emulator authors, including two versions that used the exact same hardware with different microcode (and therefore different abilities). So it's been done before at least.

DSP's are like processor units in GPU. Optimized for fast and parallel multiply and add computations (and some other basic signal processing stuff). One codec is not that much different from other from computation point of view.

The accelerator units are usually filters that operate over a region of memory while processor is busy computing something else. These can be made fixed function, however most of them are programmable to support multiple steps in codec processing.

DSPs are programmable, limited functionality, computers.

TI I believe is the largest vendors of DSPs for hardware decoding/encoding

http://focus.ti.com/dsp/docs/dsphome.tsp?sectionId=46&DC...

Presumably the next Android Dev phone will have a SoC that supports WebM... otherwise yes this move is toothless.

Someone else's SOC?

Yes. The only smartphone makers that I can think of that design their own chips are Apple and Samsung.

Your assumption is valid only in case when you don't count smartphone makers that actually design their own complete phones and not license baseband implementation from someone :)

To clarify, I meant choose option C) a SOC that supported my requirements.

But it is not sure whether Apple will adopt them. Could the competition with iPhones have influenced this decision?

which means that not one of the tablet/mobile devices out there right now supports webM.

is that true? how many released mobile devices have hardware support for the webM decoder?

None. And its likely that software decoding of WebM will behave on mobile devices the same way Flash behaves. Okay in newer devices, but laughable in previous generation devices.