Re: Codecs for <video> and <audio>

Hi, Joe, David-

I'm hearing mixed messages from Apple (not surprising, of course, given 
the size of the company).  I truly appreciate the attitude you two have 
about this issue, and I know you're doing advocacy within Apple.

But on the other hand, I read Hixie's representation of the case [1], 
and Apple seems not to be helping much at all, and may in fact be part 
of the problem.

[[
    Apple refuses to implement Ogg Theora in Quicktime by default (as used
    by Safari), citing lack of hardware support and an uncertain patent
    landscape.

    Google has implemented H.264 and Ogg Theora in Chrome, but cannot
    provide the H.264 codec license to third-party distributors of
    Chromium, and have indicated a belief that Ogg Theora's quality-per-bit
    is not yet suitable for the volume handled by YouTube.

    Opera refuses to implement H.264, citing the obscene cost of the
    relevant patent licenses.

    Mozilla refuses to implement H.264, as they would not be able to obtain
    a license that covers their downstream distributors.
]]

[[
  2. The remaining H.264 baseline patents owned by companies who are not
     willing to license them royalty-free expire, leading to H.264 support
     being available without license fees. => H.264 becomes the de facto
     codec for the Web.
]]

As I understand it, Apple and Nokia are among the chief patent holders 
for H.264.  I'm sure it's naive of me, but can't Apple approach MPEG-LA 
to reexamine the costs and benefits of having the H.264 decoder 
available under a Royalty Free license for both desktop and mobile 
implementations of HTML5 (and SVG)?  Ideally, this would also apply to 
the encoder for authoring tools, but I know that might be a harder sell. 
  Perhaps smaller patent holders could be persuaded that it's in their 
financial interest to sell their IP rights, and the cost could be 
absorbed by the browser vendors and/or a grassroots funding campaign? (I 
know I'd donate!)

Failing that, can't Apple take another look at implementing Ogg Theora, 
or do a thorough patent review in combination with other implementers? 
I find it hard to believe that this is out of the range of resources for 
a combination of Apple, Mozilla, Google, Opera, and possibly Microsoft.

Not to be too idealistic, but isn't the point of standards that a 
collection of companies decide that is in their mutual interest (and the 
interest of the public good) to pool resources to level the playing 
field?  What coordination needs to be accomplished here, and is there 
will among browser vendors to do it?

[1] 
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020620.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Joe D Williams wrote (on 6/30/09 10:38 PM):
>> The downside to requiring them would be the implication that
>> requirement implies recommendation, that's all.
>
> Having some 'required' forms for <audio> and <video> represent a
> possible path to build a native functionality for the W3C browser.
> Without a 'native' player that only, yes only, handles the specified
> types, then authors and users do not advance pat html3 because they are
> still at the mercy of the 'house' or OS built-in web media system that
> the user may have chosen to work as the plugin for the brwoser. For
> audio and video, I think the only sniffingf that should be done is to
> assure that the file MIME, content type, and maybe internal structure
> match the 'required' media types listed in the HTML 5 spec. If not, then
> the audio or video should fallback to <object> structure to handle the
> media using a plugin.
>
> Maybe the list of required formats to support would get longer if patent
> holders would agree to allow free use of the tech only in HTML 5 <audio>
> or <video> elements.
>
> I think at this stage in the evolution of making audio and video first
> class media objects, the open and free resources are rare. And, the
> competition in the great media super systems is consistently advancing
> and growing. By sticking to something simple and restricted, and open,
> and treated as 'native' then HTML 5 can route around the fevered
> competition in the media systems arena and arrive at the simple native
> player that is needed.
>
> When I first saw the node descriptions these were simple functional
> elements not that much different than other embedded content just aimed
> at providing a 'native' form. It seems to me it is evolving back to the
> point where we are most concerned with dealing with existing commercial
> 'plugins' and not a 'native' player.
>
> Thanks for all efforts in bringing a user-oriented solution to what to
> do with <audio> and <video>. Making a list of required 'native'
> encodings that are expected to be supported in HTML 5 is not that much
> different than defining which of the four or five <img> mimes are
> required or recommended.
>
>> Wave/PCM, and AVI/MotionJpeg+PCM are easily supported and OK for some
> uses (short content).
>
> Glad to see the possible list is increasing with avi and others. As long
> as thehe encoding/decoding is unrestircted, or even just restricted to a
> W3C browser running HTML 5, and free, then the candidate list can grow.
> Can we imagine that these 'native' media nodes could free us from plugin
> land and could have as big an effect of extending authoring choices for
> our WWW as development of the <img> element?
>
> Thanks and Best Regards,
> Joe
>
>> --
>> David Singer
>> Multimedia Standards, Apple Inc.
>

Received on Thursday, 2 July 2009 21:53:44 UTC