Re: ISSUE-24 (ogg-delete): Request to delete "should support Ogg" clause before publishing FPWD [HTML 5 spec]

I should also add that, due to several requests in the position papers,
the topic of the video element in HTML5 will be on the agenda of the
Video workshop [1]. While the workshop won't have a lot of time to
discuss about it, there will be several presentations to touch on it at
the minimum. Who knows, the discussion at the workshop might even help
the HTML Group...

Philippe

[1] http://www.w3.org/2007/08/video/agenda.html#s2

On Mon, 2007-12-03 at 10:40 -0800, Dave Singer wrote:
> At 2:25  +0000 1/12/07, HTML Issue Tracking Issue Tracker wrote:
> >ISSUE-24 (ogg-delete): Request to delete "should support Ogg" clause 
> >before publishing FPWD [HTML 5 spec]
> >
> >http://www.w3.org/html/wg/tracker/issues/
> >
> >Raised by: Michael(tm) Smith
> >On product: HTML 5 spec
> >
> >Date: Fri, 30 Nov 2007 16:05:30 +0200
> >From: mikko.honkala@nokia.com
> >To: connolly@w3.org, public-html@w3.org
> >Subject: RE: Request for clarification on HTML 5 publication status 
> >(ISSUE-19)
> >
> >we see benefit to publish a first WD of the HTML5 spec. To avoid any
> >patent issues we request deletion of the following clause from the spec
> >before it is published. We support publication under the condition this
> >change is made.
> >
> >>  "User agents should support Ogg Theora video and Ogg Vorbis audio, as
> >>  well as the Ogg container format." in 3.14.7.1.
> 
> We had a good discussion on this issue in Cambridge which I 
> summarized below.  I also discussed this matter with Philippe Le 
> Hegaret.  It's clear that work is needed here.  It seems as if come 
> of the current discussion is treating the current text (should...ogg) 
> as proposed 'final' text, and people are proposing replacements for 
> it.  Actually, I see it as a placeholder;  we know we'd like to reach 
> consensus on a mandated format (must...something) but we don't see 
> how to get there.
> 
> In the meantime, could we put in the spec. something like this?
> 
> ..."must (preferred)/should [TBD] support the following container 
> formats, containing the following codecs [TBD;  for example "should 
> support Ogg Vorbis and Theora in an Ogg container]."
> 
> That makes it clear that we do not yet have consensus and that we 
> have not yet reached our desired position of a mandate.
> 
> As we said in Cambridge, this is an issue of IPRs, business-risk 
> assessment, and licenses, and most of us are engineers, employed at 
> companies that may be perceived as having interests in particular 
> directions, not IPR or risk-assessment experts, and not generally 
> allowed to read patents or talk about licenses.  This is not a recipe 
> for a fruitful discussion.
> 
> * * * * * * * * Repeat summary * * * * * * *
> 
> 
> Preamble:
> 
> The HTML5 specification contains new elements to allow the embedding 
> of audio and video, similar to the way that images have historically 
> been embedded in HTML.  In contrast to today's behavior, using 
> object, where the behavior can vary based on both the type of the 
> object and the browser, this allows for consistent attributes, DOM 
> behavior, accessibility management, and so on.  It also can handle 
> the time-based nature of audio and video in a consistent way.
> 
> However, interoperability at the markup level does not ensure 
> interoperability for the user, unless there are commonly supported 
> formats for the video and audio encodings, and the file format 
> wrapper.  For images there is no mandated format, but the widely 
> deployed solutions (PNG, JPEG/JFIF, GIF) mean that interoperability 
> is, in fact, achieved.
> 
> Licensing:
> 
> The problem is complicated by the IPR situation around audio and 
> video coding, combined with the W3C patent policy 
> <http://www.w3.org/Consortium/Patent-Policy-20040205/>. "W3C seeks to 
> issue Recommendations that can be implemented on a Royalty-Free (RF) 
> basis."  Note that much of the rest of the policy may not apply (as 
> it concerns the specifications developed at the W3C, not those that 
> are normatively referenced).  However, it's clear that at least 
> RF-decode is needed.
> 
> Candidates:
> 
> There are, of course, a number of codecs and formats that can be 
> considered.  A non-exhaustive list might include a variety of 
> 'public' codecs, as well, of course, as proprietary ones:
> 
> a) open-source projects:  the ogg family (vorbis, theora), and the 
> BBC Dirac video codec project
> b) Current ISO/IEC (MPEG) standard codecs, notably the MPEG-4 family: 
> AVC (14496-10, jointly published with the ITU as H.264), AAC (part of 
> 14496-3)
> c) Older MPEG codecs, notably MPEG-2 layer 3 (aka MP3), MPEG-2 layer 
> 1 and 2 audio, and maybe MPEG-4 part 2 video (14496-2)
> d) Current standard codecs from other bodies;  SMPTE VC-1, for example
> e) Older standards from other bodies:  ITU recommendations H.263 
> (with or without its many enhancement annexes) or even H.261
> f) Very old standard codecs, formats, or industry practices;  notably 
> the common format for video from digital still cameras (Motion JPEG 
> with uncompressed audio in an AVI wrapper)
> g) Proprietary codecs, such as Dolby AC-3 audio
> 
> Candidate concerns:
> 
> There are concerns or issues with all of these:
> a) a number of large companies are concerned about the possible 
> unintended entanglements of the open-source codecs; a 'deep pockets' 
> company deploying them may be subject to risk here;
> b) the current MPEG codecs are currently licensed on a royalty-bearing basis;
> c) this is also true of the older MPEG codecs;  though their age 
> suggests examining the lifetime of the patents;
> d) and also SMPTE VC-1
> e) H.263 and H.261 both have patent declarations at the ITU. 
> However, it is probably worth examining the non-assert status of 
> these, which parts of the specifications they apply to (e.g. H.263 
> baseline or its enhancement annexes), and the age of the patents and 
> their potential expiry.
> f) This probably doesn't have significant IPR risk, as its wide 
> deployment in systems should have exposed any risk by now;  but it 
> hardly represents competitive compression.
> g) Most proprietary codecs are licensed for payment, as that is the 
> business of the companies who develop them.
> 
> Other licensing concerns:
> 
> It's also possible that there are other issues around licensing:
> a) variations in licensing depending on filed patents in various geographies
> b) restrictions on usage, or fees on usage, other than the fees on 
> implementation (e.g. usage fees on content sold for remuneration).
> 
> It's not entirely clear, also, whether 'implementing' HTML means the 
> ability to decode and display, or whether encoding is also included. 
> Including encoding in the equation might significantly complicate 
> matters.
> 
> Possible action:
> 
> The members of the WG are engineers, not IPR experts. There is 
> general consensus that a solution is desirable, but also that 
> engineers are not well placed to find it:
> a) they are not experts in the IPR and licensing field;
> b) many of them are discouraged by their employers from reading 
> patents or discussing IPR.
> 
> It's clear that the December workshop cannot be silent on this 
> subject.  There must be recognition of the issue and evidence of at 
> least efforts to solve it, and preferably signs of progress.
> 
> It is probable that this is best handled in parallel with the 
> technical work, and headed by someone 'technically neutral' and 
> qualified, such as W3C technical and legal staff.  A good start would 
> be to:
> a) examine the declaration, licensing, and patent expiry situation 
> for various codecs;
> b) contact the licensing authorities for various codecs to determine 
> their level of interest and flexibility, and possibly invite them to 
> the December workshop.
> c) analyze the open-source codecs for their risk level, and possibly 
> seek statements from patent owners if that is deemed prudent;
> 
>

Received on Monday, 3 December 2007 18:54:15 UTC