[whatwg] The issue of interoperability of the <video> element

Jerason Banes schrieb:
> On 6/26/07, *Maik Merten* <maikmerten at gmx.net
> <mailto:maikmerten at gmx.net>> wrote:
>     Opera and Mozilla already have implemented (early) Ogg Vorbis and Ogg
>     Theora support.
> And (if this thread is any indication) are likely to be the only ones.
> Internet Explorer still holds the majority of the market, and Safari is
> still the predominant browser in the Mac market.

Microsoft isn't part of WHATWG. If they implement <video> due to "market
demands" they'll most likely push WMV no matter what is discussed here.
That doesn't mean we should support WMV usage on the net.

>     Plus "what is lack of support"? Encoding apps for Ogg Theora are
>     available on basically every platforms, as are players (yes, even
>     Windows Media Player and QuickTime player can play it with the fitting
>     components installed, same goes for RealPlayer). It's absolutely trivial
>     to encode content for it.
> The same can be said for H.263 and MPEG4. Linux machines can play these
> codecs with no issues as long as the codecs are installed separate from
> the distro itself. The question that I hate to ask (because it goes
> against my own grain to ask it) is, which is more useful to the web
> market: Asking Windows users to install Ogg/Theora codecs or asking
> Linux users to install H.263 codecs?

Users that download unlicensed MPEG decoders are in a legal grey area
depending on where you live (actually it may be darker than just grey).
It's not an option to suggest people shall ignore the licensing fees. Of
course they could buy licensed decoders - but assuming people will spend
money just to enable "proper" <video> support in their browsers isn't

Users on all platforms, however, can download and install a codec with
free licensing terms without problems.

> Given that Linux has an extremely
> small desktop share consisting of expert users, I'm forced to answer
> that they would be far less impacted by a baseline support of H.263 than
> Windows users will be impacted by a baseline support of Theora.

Every single user will - if at all - have to install whatever codec
*once*. Same for Linux and Windows and Mac. People choosing a browser
with e.g. Theora support won't have to bother at all.

>     Free Software like Mozilla cannot implement MPEG4 or H.263 and still
>     stay free. The "tax" *is* an issue because you can't buy a "community
>     license" that is valid for all uses.
> Indeed. That's why I asked how feasible it is for these browsers to plug
> into underlying media players? On windows that would be WMP, Quicktime
> on Macs, and libavcodec on Linux/Unix.

Windows doesn't come with H.263 or MPEG4 (e.g. Part 2) support by
default. Oh, and you'd give Microsoft the power to simply drop whatever
support they ship and "force" things down to WMV.

Oh, and you can't take libavcodec for granted. Even if it is installed
on some systems: I wouldn't be surprised if most installations are not
properly licensed. I'm not aware of any way to get a properly licensed
libavcodec (which implements basically every format known on earth - and
which therefore may infringe basically every patent ever filed in that

To my knowledge there's not one single suitable audio/video codec
combination that is installed by default on Windows, Mac and Linux.

>     Plus even if you implement H.263 or MPEG4 video - what audio codec
>     should be used with that? Creating valid MPEG streams would mean
>     using a
>     MPEG audio codec - that'd be e.g. MP3 or AAC. Additional licensing costs
>     and additional un-freeness.
> Correct me if I'm wrong, but that depends on the container format,
> doesn't it? If we use the MPEG container format, then yeah. MP3 is
> pretty much a guaranteed necessity. However, I am not aware of any
> encumbrances (*grits teeth again*) with the AVI container format. Which
> would allow for a less-performant baseline like an ADPCM format, which
> is at least an open standard.

ADPCM is not suitable for web usage. After all we still want to have
some bits left for video, right? ;-)

> Of course, I'm probably going to have to bow to my own argument and
> agree that the market would never accept such a low audio baseline.
> Which means that something like MP3 or AAC would indeed be a requirement.

There's a reason why free software avoids these codecs.

>     Don't get me wrong: MPEG technology is nice and well performing - but
>     the licensing makes implementations in free software impossible (or at
>     least prevents distribution in e.g. Europe or North America).
> It is a difficult conundrum. If the WHATWG specifies theora, then it
> runs the risk of being ignored. If it specifies an existing format then
> it runs the risk of locking out some small cross-section of users. My
> argument is based around the "devil you know" approach that the WHATWG
> has otherwise adopted in its standards. It rubs me the wrong way to
> suggest it, but I don't see any other way of ensuring that HTML5 video
> would become as ubiquitous as FLV video has become.

Actually the WHATWG *doesn't* force any codec. It merely sorta
*recommends* one set of free codecs. All implementations supporting one
codec would be nice, but looking at the discussion this won't happen. I
assume Apple will support the MPEG codecs (they're paying for them
anyway, so from their perspective there is little reason to not use
that) and perhaps (hopefully) will come up with a clever way to enable
their users to install said set of free codecs from a 3rd-party source
to improve interoperability with the two other big alternative browser
vendors. Opera and Mozilla either can't (Mozilla) or don't want (Opera)
to license the MPEG codecs. Oh, and of course some HTML5 devices may not
be able to support <video> at all, so it would make little sense to
require any set of codecs.

The only thing that WHATWG could specify would be something like "User
agents SHOULD support Ogg Vorbis and Ogg Theora and/or other formats
that don't require licensing fees. User agents that can't implement
those codecs but still want to offer media functionality MUST support at
least one audio/video codec combination that is accessible under fair
terms to everyone." or whatever.

Maik Merten

Received on Tuesday, 26 June 2007 11:52:05 UTC