W3C home > Mailing lists > Public > public-html@w3.org > July 2009

proposed audio/video codec text

From: Rob Sayre <rsayre@mozilla.com>
Date: Tue, 07 Jul 2009 18:34:25 -0400
Message-ID: <4A53CD71.10707@mozilla.com>
To: HTML WG <public-html@w3.org>
I'd like to get feedback on the proposed text below.

If you have already repeatedly stated your opinion on the virtues of 
Ian's approach, there is no need to reply to my message. Also, this is 
not a change request addressed to Ian.

Rationale:
The goal of each W3C Working Group is to produce a Recommendation that 
is not only technically sound, but that can be implemented according to 
the W3C Royalty-Free License requirements. [1] I suspect this issue is 
polarizing because some feel that audio/video elements without credible 
baseline codecs serve as a trojan for encumbered content, but clients 
supporting only encumbered codecs could claim to conform to an open, 
interoperable W3C specification.* A secondary concern is that, aside 
from failing to meet W3C RF goals, the specification is lying by 
omission in purporting to specify an interoperable Web, but failing to 
note that more than one video file could be needed to satisfy all 
popular clients. This proposal attempts to rectify both concerns by 
requiring Vorbis/Theora for conforming clients and noting that some 
popular clients and environments are not currently capable of meeting 
this conformance requirement.

Proposal:
Add the following to the video/audio element sections:
"User Agents MUST support the [OggTheora/OggVorbis] codec as a source 
for the video/audio element. At the time of this writing, some popular 
clients and environments are not currently capable of meeting this 
conformance requirement, so authors should be aware that additional 
media resources might be necessary."

Closing notes:
I feel this UA requirement (it is not an authoring requirement) is both 
more accurate with regard to current practicalities and more faithful to 
the goals of the W3C.

thanks,
Rob

* It is true that other elements exist to do just this sort of thing, 
but they are not generally referred to as W3C HTML5 technologies, and we 
already have evidence of interoperability failures among clients 
claiming to conform to HTML5. See for example: 
http://www.youtube.com/html5. A look at the source reveals the following 
markup:

<video width="640" height="360" src="/demo/google_main.mp4?2" autobuffer>
<div class="video-fallback">
<br>You must have an HTML5 capable browser.
</div>
</video>

[1] http://www.w3.org/2004/02/05-patentsummary.html
Received on Tuesday, 7 July 2009 22:35:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:40 GMT