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

Re: proposed audio/video codec text

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 07 Jul 2009 16:03:34 -0700
Cc: HTML WG <public-html@w3.org>
Message-id: <52D14647-1F83-466D-A89E-3135EA7D886A@apple.com>
To: Rob Sayre <rsayre@mozilla.com>

On Jul 7, 2009, at 3:34 PM, Rob Sayre wrote:

> 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.

I have two comments that I have not previously given in reply to Ian:

1) Since your proposed text implies that there may be valid reasons  
not to meet the requirement, according to RFC2119 it should be a  

2) The patent license/disclaimer for Theora facially appears to only  
apply to modified versions of the VP3 code (including Theora, since it  
is derived from the VP3 code base), but not to independent  
implementations. I think this would be insufficient for W3C Patent  
Policy purposes; the Patent Policy limits what strings may be attached  
to a qualifying royalty-free license to an Essential Claim, see <http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements 
 >. I have asked the Theora developers to clarify and resolve the  
situation: <http://lists.xiph.org/pipermail/theora/2009-July/ 
002415.html>. In that email you can also find details explaining why  
the VP3 patent license appears to have strings attached. Besides a  
clarification from Xiph/VP2, another possibility is for the W3C to  
form a PAG, which could decide this is not a problem in practice.  
Reducing the requirement from MUST to SHOULD would make related patent  
claims automatically not Essential Claims, although that argument  
would also arguably apply to any other codec.


> 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 23:04:19 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:47 UTC