Re: Codecs for <video> and <audio>

Maciej Stachowiak wrote:
> 
> On Jul 4, 2009, at 4:10 AM, Sam Ruby wrote:
>>
>> I guess that would depend on what you presume my purpose in asking 
>> this question is.
>>
>> Your claim that common codecs aren't required for interop baffles me. 
>>  I believe that "Because this isn't required for interop" to be a 
>> false statement.  I very much believe that video is a valuable feature 
>> of HTML5, but *only* if there is a common, royalty free codec that is 
>> implemented across compliant implementations.  If that isn't the case, 
>> then the video element should be deferred (either to HTML6 or by 
>> naming the next release HTML4.2 or somesuch, I care not).
> 
> Can you explain the benefits of not specifying the <video> element at 
> all, relative to specifying it without a required codec? Earlier, I 
> posted some markup that will work across all browsers currently 
> implementing <video> or that have announced future support, in response 
> to your comments, but you didn't reply. Here is an example of a useful 
> Web page that uses the dual encoding technique: 
> <http://www.mozilla.com/en-US/firefox/performance/>. Do you think it 
> would be an improvement to make such markup noncomforming and its 
> behavior unspecified? If so, why?

That's not what I'm advocating.

Let's start with the most obvious, and start with the exact page that 
you describe.  That page starts with a DOCTYPE of xhtml1-strict.  The 
obvious conclusion is that browsers that currently implement <video> do 
so without requiring HTML5.

Second, if interoperability were the sole consideration, then a spec 
that said that in order to be conformant, all video elements much 
provide both a H.264 and OGG alternatives, and all user agents that 
purport to implement HTML5 must implement at least one of these codecs. 
  However interoperability is not the sole consideration here in that a 
requirement that authors must implement a non-royalty free codec is not 
something I would support as a Recommendation.

Third, I didn't say nonconforming.  How to build useful conformance 
checkers in a world where people continue to create new tags and 
attributes is a (separate) open question.  There are lots of useful 
pages that the current HTML5 considers non-conformant, merely because 
they happen to use tags or attribute that are no longer considered in 
vogue or are defined in other specifications.  I happen to consider that 
a bug, not in those pages, but in the spec.

I believe that in the fullness of time, the video element should be 
fully documented, in HTMLn for some value of "n", and people who don't 
have need for hardware support or higher levels of quality of bits 
should be able to rely on the fact that such usage of the royalty free 
codecs enumerated in the specification will interoperate across all 
browsers that implement that version of the specification.

Until then, people can continue to build useful pages that use the video 
element in pages authored to versions of [X]HTML less than "n".

> Regards,
> Maciej

- Sam Ruby

Received on Saturday, 4 July 2009 15:41:31 UTC