[whatwg] Codecs for <audio> and <video>

[Gregory Maxwell]

On Wed, Jul 1, 2009 at 12:35 AM, Maciej Stachowiak<mjs at apple.com> wrote:
> For the mobile phones where I have specific knowledge regarding their
> components, I am not at liberty to disclose that information.

Unsurprising but unfortunate.

There are other people trying to feel out the implications for
themselves whom are subject to different constraints then you are, for
whom the "take my word for it" is less than useless since they can
only guess that the same constraints may apply to their situation.

> I can tell you that iPhone does not do H.264 decoding on the CPU.

Iphone can decode Theora on the CPU. I don't think really isn't even a
open question on that point. It's an important distinction because
there are devices which can decode theora on the primary cpu but need
additional help for H.264 (especially for things beyond base-profile).

> No one doubts that software implementations are available. However, they are
> not a substitute for hardware implementations, for many applications. I
> would expect a pure software implementation of video decoding on any mobile
> device would decimate battery life.

Then please don't characterize it as "it won't work" when the
situation is "it would work, but would probably have unacceptable
battery life on the hardware we are shipping".

The battery life question is a serious and important one, but its
categorically different one than "can it work at all".  (In particular
because many people wouldn't consider the battery life implications of
a rarely used fallback format to be especially relevant to their own
development).

> I would caution against extrapolating from a single example. But even here,
> this seems to be a case of a component that may in theory be programmable,
> but in practice can't be reprogrammed by the device vendor.

Yes, I provided it to balance the OMAP3 example I provided. It a case
which is not as well off as the as a widly used, user programmable
general purpose DSP based devices but still not likely to be limited
by fixed function hardware. It's programmable, but only by the chip
maker.

>> There is, in fact, a synthetically VHDL implementation of the Theora
>> decoder backend available at http://svn.xiph.org/trunk/theora-fpga/
>
> I did not mention FPGAs because they are not cost-competitive for products
> that ship in volume.

Of course not, but the existence of a code for a syntheizable hardware
description language means that the non-existence of a ASIC version is
just a question of market demand not of some fundamental technical
barrier which you appeared to be implying exists.


> Silvia implied that mass-market products just have general-purpose hardware
> that could easily be used to decode a variety of codecs rather than true
> hardware support for specific codecs, and to the best of my knowledge, that
> is not the case.

There are mass market products that do this.  Specifically palm-pre is
OMAP3, the N810 is OMAP2. These have conventional DSPs with publicly
available toolchains.

It seems like in both cases broad vague claims are misleading.


I'd still love to see some examples of a web browsing device on the
market (obviously I don't expect anyone to comment on their unreleased
products) which can decode H.264 but fundamentally can't decode
Theora.  The closest I'm still aware of is the WDTV I mentioned
(which, does not have enough general CPU power to decode pretty much
any video format, and which uses a video engine which can only be
programed by its maker).

I understand that you're not at liberty to discuss this point in more
detail, but perhaps someone else is.

Likewise, I'm still curious to find out what webpages are claiming
that implementation on common DSPs would be unusually difficult.


Cheers,