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.

not sure

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

Sorry, I may be overdoing it, I am specifically thinking of the 
<audio> node  as 'native' to the browser. Not as a plugin. An author 
should always use <object> or, obsolete in my mind <embed> to get the 
"house" multimedia system. Same for <video> I was thinking that, like 
of media forms 'native' to html, the idea was that for a certain  web 
standard sort of media that the vendor was not any sort of issue.  So, 
from that view, what does Quicktime have to do with it?


>
>    Google has implemented H.264 and Ogg Theora in Chrome, but cannot
>    provide the H.264 codec license to third-party distributors of
>    Chromium, .
>

Well, Youtube is a market, but I would be surprized if they expected 
their vast customer and application base to be served by <audio> 
and/or <video>. Just as <canvas> may not do some stuff they need from 
a propretary source. At least now mostly they use <object> element 
thanks to all the brwoser makers who make that possible.

>  and have indicated a belief that Ogg Theora's quality-per-bit
>    is not yet suitable for the volume handled by YouTube

It proably takes more client power and more bits so you need more 
memory and a faster processor. I would be glad to sample some. If this 
stuff is easy to find, I can look. Any links out there?

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

This may be a problem, I don't know because I have missed discussion. 
In short, I may be comepletely oblivious to the actual situation and 
just happen to have access to enough of range of the available tools 
and lucky that I just haven't noticed, plus wihing for the very 
best:).

It seems like all of the W3C browser makers would have the same 
comment. Or, somebody could say hey look over here this one is free. 
It is just an entry level <audio> node at this time:)
 .
>
>    Mozilla refuses to implement H.264, as they would not be able to 
> obtain
>    a license that covers their downstream distributors.
> ]]

I have seen situations where the licence is granted only in certain 
applications, for instance only allowed in W3C browsers via the 
<audio> element.


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


That sounds fine. So then it could be added to the list in or 
associated with the W3C HTML 5 stuff if the W3C browser makers wanted 
to do that at that time.

> 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!)
>

This is a great attitude. I am guessing that SVG has an audio 
functionality?
A link to that might help..There is always something new and these 
days some  platform specials. That is a very busy and evolving part or 
this WWW. .

The thing is, it's for the good of the web. Earlier I somehow compared 
these elements with <img> because it took a long time to get where we 
are today with the typical html browser.


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

Maybe if those can agree on basic HTML 5 parsing and sniffing, there 
is opportunity.

Also, you left out a few more that might be interested, like 
realplayer and adobe and few other media player systems.

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

I like that a lot. It is, it is. It needs to be simple and non 
threatening, maybe?

 For a media element to be truely a first class object, it means I 
really don't care who produces it. Since we already have <object> 
working much more reliably for stuff like the entire range or embedded 
interactive multiple media connections we could possibly want to play 
with, I saw the <audio> and <video> nodes as relatively simple things 
that only played stuff that everybody agreed on, the 'free' ones - for 
W3C browser makers, maybe free as in free puppy. To me looking at 
those element in two ar three years, I might think that golly, all 
those browser makers got together and produced real nice things for me 
to start out on.

Now that I am thinking more about it, I hope that the main high end 
media systems  will redo their control sets to all be the same subset 
rather than just wrap their system with the HTML 5 media interfaces of 
the <audio> and <video> elements. Then <object> would be easier to use 
over a range of big time and popular players. Also,  from the peanut 
gallery is that surely it will be to the best interest of every W3C 
browser maker to make sure an author cannont inject or instance any 
'plugin' for the element and only the 'native' unbranded player can 
run in <audio> or <video>..

Maybe too much now, but first, it is implementations of these 
elements. Any links? I will test some stuff or provide some files.

Still I would suggest starting <audio> testing with .wav PCM and 
whatever .ogg..Seems like somebody whould have a chart up there 
telling who is doing what. If these important nodes are kept simple, 
the it will be more fun for everyone as well as a doable introduction 
to the vast species of audio and video environments. The competition 
for who has the most capable and friendly branded audio and video 
browsing system can only be addressed either freestanding or as 
<object> content, I was thinking. Not in these nodes of which I would 
expect to be having several  of both types running and ready to run at 
any given moment without big host load. .

Thanks and Best Regards,
Joe

>
> [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 Friday, 3 July 2009 01:40:21 UTC