[whatwg] on codecs in a 'video' tag.

[Maik Merten]

Dave Singer schrieb:
> We'd really like to get to a good design on this, as the mess of
> embed/object plug-ins we feel is limiting both functionality and
> interoperability.

Yeah, and the work to get good functionality into the <video> element
obviously can and should go on without having to worry about codecs at all.

Once the implementation work starts the topic of codecs will inevitably
matter again and I hope this won't lead to a media-format fragmentation
that hinders interoperability.

> It would be tempting to go into a discussion of the IPR concerning the
> baseline of H.264, but it's really off-topic and obviously delicate.

You're right.

>> And to make matters worse you of course need a MPEG audio codec, too,
>> which adds to the overal costs.
> 
> well, you could match an mpeg video codec with an audio codec from
> somewhere else, technically.

Yeah, but that'd mean you'd come up with a "Frankenstein" format that is
neither free nor a standard of any kind. However, you're just pointing
out the technical possibility.

> I think the example of SVG (a 'markup' language) having a codec
> requirement that 3GPP then had to explicitly write-out is instructive. 
> The attempt there didn't work.

Well, if 3GPP chose to write out a required format they obviously wanted
to violate the spec without getting blamed for violating it ;)

In case of WHATWG, which primarily is "just" Apple, Mozilla and Opera I
guess such spec-mangling should be unnecessariy, especially if the spec
only mentions special formats as an optional thing.

Personally I fear that once <video> is out in the wild without a free
base format getting promoted Microsoft sooner or later will join the
party with a Windows Media only implementation and effectively sabotage
the WHATWG efforts of interoperability without even having to take the
blame for ignoring the base format. That's just a theoretical
possibility, but I think it doesn't harm to "harden" the spec against
such "hacks".

Actually the current <audio> draft requires user agents to support PCM
in a .wav container (that's way stronger than what can be found in the
<video> section). I guess your points apply there, too?


Maik Merten