W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

From: David Singer <singer@apple.com>
Date: Mon, 27 Feb 2012 15:36:11 -0800
Cc: Adrian Bateman <adrianba@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, David Dorwin <ddorwin@google.com>
Message-id: <2B4D4D5F-DCFE-4E9E-AF98-1F3BEE9E4602@apple.com>
To: Mark Watson <watsonm@netflix.com>
Mark

that's fine;  I can see the desire to be able to do *more*.  I just don't like people being told that something is not possible, when at least aspects of it are.  It makes it looks as if the improvement proposal needs a stronger justification than it actually has, which actually weakens the proposal.

Dave

On Feb 27, 2012, at 13:34 , Mark Watson wrote:

> 
> On Feb 27, 2012, at 10:12 AM, David Singer wrote:
> 
>> 
>> On Feb 21, 2012, at 15:16 , Adrian Bateman wrote:
>> 
>>> Many content providers and application developers have said they can't use <audio>
>>> and <video> because HTML lacks robust content protection. 
>> 
>> 
>> I'd really appreciate it if myths like this were not propagated.  HTML5 says nothing at all about the format of embedded media resources.  If the platform supports robust content protection, they are as playable as anything else.
> 
> David,
> 
> That is not strictly correct: many browsers include the entire media pipeline in browser code, so even if the "platform" on which they are running supports content protection it will not be accessible through HTML5.

In that case, the platform is the 'web platform', and it don't do nothing useful, true.

> It is true, though, that if a browser makes use of a platform-provided media pipeline and this supports content protection then content protected that way may be playable - if the provider has the right kind of content-protection-system-specific front-end servers available. Also true if the browser itself implements the content protection scheme.

concrete example (not terribly useful as given) - if you have a .m4p (protected audio file) in your iTunes library on a mac, you'll find that safari plays it just fine (just drag it in, you don't need to write a page).  True, if I send you a .m4p file that I licensed that you also have a license for, I am fairly sure it won't play, but that's a question of what content owners want to have work (and we're willing to make work) as much as it is technological.

> But it is certainly not a myth that many content providers and application developers say they can't use <audio> and <video> because of the lack of a standard way in HTML to access such features. That is certainly the case for Netflix, together with some other reasons. That content protection is frequently cited as a reason for using Flash or Silverlight is also evidence that there is something missing in HTML. The reason is not that it absolutely cannot be done with the HTML specification as it is, but that too much coordination is needed between content provider, browser and platform to make that practical.

Improvement is always possible.

> By defining a standard architecture and decoupling service-specific and content-protection-specific aspects, we make it much easier to create a service supporting a diversity of browsers and devices based on a diversity of protection systems.
> 
> ...Mark
> 
>> 
>> Similarly the proposal itself starts with the same flawed implication, that protected content cannot be played in HTML5:
>> 
>> "This proposal extends HTMLMediaElement to enable playback of protected content. "
>> 
>> 
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>> 
>> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Monday, 27 February 2012 23:37:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:46 GMT