Re: Codecs for <video> and <audio>

> 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 Wednesday, 1 July 2009 02:39:18 UTC