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

timeless timeless at gmail.com
Wed Jul 1 04:01:02 PDT 2009


On Wed, Jul 1, 2009 at 8:54 AM, Gregory Maxwell<gmaxwell at gmail.com> wrote:
> 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.

Hrm, I worked on the n810 (nowhere near DSP, thankfully, although I
did get to hear people crying).

The technical existence of a generic DSP does not a useful implementation make.

So, can you please give me the url for a useful DSP codec I can
install on my n810 (it runs Maemo 4.1 "Diablo", and no, asking me to
install your own custom platform just to play video isn't OK) ?

Hypothetically, just getting the stuff the vendor offers working in a
shape which is shippable is depressingly hard.

I really hate the double and triple standards espoused here.

For lack of a better reference, however i trust that you're capable of
finding hundreds (as a google search [battery life claims] did for
me),

http://www.techradar.com/news/computing-components/lawsuits-planned-over-laptop-battery-life-claims-612614

and adding the word 'cell' leads to:
http://reviews.cnet.com/cell-phone-battery-life-charts

I have nothing to do with the 5800 and don't have any idea what it is,
but it was on the first page of results, so:
http://www.wirelessinfo.com/content/Nokia-5800-Cell-Phone-Review/Battery-Life.htm

Summarily, it said that getting 75% of the claimed battery life was
respectable (not stellar). I think it's safe to say that consumers
really do care about battery life (and at least with laptops are
starting to complain violently).

I have no idea about purchasing costs (again, we work on software),
but I think people will accept that the cost for an FPGA is orders of
magnitudes higher than and not commercially viable in contrast to
ASICs.

Let's consider a different position. If you heard that a hardware
vendor had a product which could decode a video format called
QuperVide and they provided an opensource implementation, but they had
a patent on another (better) technique for decoding QuperVide which
they used in their ASIC. Would you support them in their bid to
mandate QuperVide as a Required codec for a Standard (e.g.
HTML5:Video)?

I'd hope that most people would say that it's unfair to mandate such a
standard which gave the QuperVide vendor a sales advantage in its
market (hardware ASICs).

Would you say: "oh, that's ok, we can standardize on this, and then 5
years from now we'll have an open source hardware implementation
that's as good"?

You could do that, but for the intervening years anyone who sells
hardware and wants to support QuperVide will have three choices: 1.
Pay QuperVide's fees for its ASICs and get tolerable battery life. 2.
Pay for an extra DSP or a faster CPU+BUS and pay a penalty in terms of
battery life. 3. Pay engineers to try to develop a competing hardware
ASIC which doesn't run afoul of QuperVide's vendor's patent for its
hardware ASIC.

I also don't like how people enjoy a good run of corporation hunting.

First you go after Microsoft. Then you go after Google. Then you after Apple.

And yes, you've already hunted Nokia, a couple of times, but I can't
remember when in the sequence it was. I guess that it's sort of open
season for corporation hunting and maybe Nokia is currently slightly
out of season. Actually, it sounds like Congress has opened up a
session there, so maybe you're just politely waiting in line.

Mozilla has sketches for adding pluggable support for its video module
too, but seems to be reticent about working on it as doing that would
distract from their open web position.

Sadly, Apple gets no points for being Pluggable on Desktop (QT has an
open API). If I were to complain about Mozilla not being open, they'd
claim "oh, we're open source, anyone can contribute". That isn't true
btw, if I were to write a pluggable module for video, their benevolent
dictator has every right to veto it. And sure, I can maintain my fork,
but just like Linus with Linux, they have every right to change their
APIs regularly to make my life hell.

Note: Microsoft, like Apple has Pluggable APIs, and again, like Apple,
people don't care, and just say "ooh, they're a bad company, they
won't play with us."

Microsoft, like Opera, like Apple, like every other company in the
world is busy working on things. Often quitely (and yes, Mozilla does
things quietly too). Opera has a policy (like Apple, like Microsoft,
like Nokia, ...) of not announcing things until they announce them.
Microsoft presumably has a roadmap and freeze features out at a
certain point in time, most companies do. Sometimes groups have to
rewrite or reorganize large portions of their code, and can't fix
certain things until then. Gecko, View Manager, Table Rewrites, HTML5
parser, lots of these things happen with Mozilla.

Heck, the ACID tests traditionally are such that the first release of
mozilla after the release of an ACID test can't possibly pass the ACID
test, because of the schedule. And while people do beat up Mozilla for
this (and it's unreasonable), the people in this group are willing to
overlook it, but don't seem to think it's ok to overlook the same
behavior in Microsoft (or ...). So Mozilla has a public roadmap, and
Opera commits to certain specs, but Opera doesn't commit to other
specs, and Mozilla e.g. isn't interested in committing to a certain
SQL spec which would force everyone to bug for bug implement
sqlite3.z.y.a.q.t where those numbers would be fairly arbitrary but
fixed forever.

The decisions of each of these groups (except the people who are busy
boiling tar and collecting feathers) are actually quite reasonable if
you look at them alone. But instead, whoever has the axe to grind or
the tar boiled and feathers ready overlooks the rest of the landscape
and just goes off and hunts down their intended victim.

ps: if you aren't familiar with a word or metaphor, please feel free
to look them up or ask me privately, I'm vaguely sorry for piling them
on, but everyone else vents, so this was my turn.


More information about the whatwg mailing list