Re: [MEDIA_PIPELINE_TF] Common content security requirements

We can play protected content with Silverlight today. Any solution in which the user has to download a plugin is no change - the whole point of the discussion should be to enable playback of protected content -without- Silverlight/Flash etc.

This does not mean browsers need to implement DRM, but they may need to hook into content protection mechanisms present on the device platform, just as they hook into media playback mechanisms today.

I don't think a 'hybrid' mechanism where selected features of Silverlight/Flash are usable through HTML is especially useful or that there's any reason to expect the vendors of those products to be interested in that.

...Mark

Sent from my iPhone

On Sep 1, 2011, at 12:04 PM, "Mays, David" <David_Mays@Comcast.com> wrote:

> I was thinking about this some more, and it occurred to me that maybe I
> haven't been clear about what I'm asking for. So allow me to elaborate:
> 
> 
> Consider the following grotesque markup:
> 
> <video id="movie" width="320" height="240" preload controls>
>  <source src="pr6.webm" type='video/webm; codecs="vp8, vorbis"' />
>  <source src="pr6.ogv" type='video/ogg; codecs="theora, vorbis"' />
>  <source src="pr6.mp4" />
>  <object width="320" height="240" type="application/x-shockwave-flash"
>    data="flowplayer-3.2.1.swf">
>    <param name="movie" value="flowplayer-3.2.1.swf" />
>    <param name="allowfullscreen" value="true" />
>    <param name="flashvars" value='config={"clip": {"url":
> "http://wearehugh.com/dih5/pr6.mp4", "autoPlay":false,
> "autoBuffering":true}}' />
>    <p>Download video as <a href="pr6.mp4">MP4</a>, <a
> href="pr6.webm">WebM</a>, or <a href="pr6.ogv">Ogg</a>.</p>
>  </object>
> </video>
> 
> This is a rudimentary fallback approach for non-HTML5 browsers, or for
> content that the HTML5 <video> element can't handle. Basically if the
> browser can't cope with the <source> elements, it will use the <object>
> element to show video.
> 
> Instead of this, consider this markup:
> 
> <video id="movie" width="320" height="240" controls>
> <source src="pr6.mp4" type="video/webm"/>
> <source src="pr6.ism/Manifest" type="application/x-smooth-streaming"/>
> </video>
> 
> In the above, if the computer had Silverlight installed and "registered"
> with the particular browser, the <video> element would delegate playback
> of the Smooth asset to the Silverlight player, which would handle the DRM
> as well as video playback for Microsoft's proprietary Smooth format. You
> could imagine the same kind of setup for an Adobe RTMPe asset as well.
> 
> This would require some kind of API that the browser would expose,
> allowing the various DRM-enabled video players or plug-ins to register as
> "handlers" for a particular type of <source> element.
> 
> Additional data could be put into the <source> element as needed, to pass
> arbitrary parameters like those seen in the <param> tags above. (Remember
> LC 13333)
> 
> Example: (Adobe's player would have registered itself to be a handler for
> "application/x-shockwave-flash" in this case)
> <source src="pr6.mp4" type="application/x-shockwave-flash"
> data-flashvars="config={"clip":
> {"autoPlay":false, "autoBuffering":true}}"/>
> 
> And if you (web developer) need to handle special cases for
> install/download of various plug-ins, the canPlayType() JS API still lets
> you provide a good experience there.
> 
> Does that help?
> 
> Dave
> 
> 
> 
> 
> 
> David Mays | sr. software architect | 15.217 | one comcast center |
> philadelphia, pa. 19103 | 215.286.3395 w | 215.847.9631 m
> ---------------------------------------------------------------------------
> -------------------------------------------------------------
> 
> 
> 
> 
> On 9/1/11 11:44 AM, "Mays, David" <David_Mays@Comcast.com> wrote:
> 
>> Why use the <video> element at all? Schemes already exist to sniff out
>> browser video/plug-in capabilities and make decisions based on that. You
>> can play basically any video you want now, using existing <object>
>> elements.
>> 
>> Using <object> as a fall-back for <video> when <video> doesn't support
>> something seems like a step sideways rather than forwards.
>> 
>> If the vendors of things like Flash and Silverlight could tie into a
>> browser API in a way that made the <video> element aware of (and able to
>> act as a rendering viewport for) their flavors of content, we wouldn't
>> need complicated detection & fallback schemes.
>> 
>> 
>> 
>> David Mays | sr. software architect | 15.217 | one comcast center |
>> philadelphia, pa. 19103 | 215.286.3395 w | 215.847.9631 m
>> --------------------------------------------------------------------------
>> -
>> -------------------------------------------------------------
>> 
>> 
>> 
>> 
>> On 9/1/11 10:56 AM, "Mo McRoberts" <mo.mcroberts@nexgenta.com> wrote:
>> 
>>> On 1 Sep 2011, at 15:37, Mays, David wrote:
>>> 
>>>> What if the browser provided APIs that would allow a DRM vendor to
>>>> override the functionality of the <video> element?
>>>> Today, if I put a URL pointing to a Smooth/PlayReady manifest into a
>>>> <video> element, the browser has no idea what to do.
>>> 
>>> Not strictly true ‹ JS can detect that the browser doesn't know what to
>>> do, and can examine the sources. Responsibly-written <video> has handoff
>>> to Silverlight/Flash anyway, and the Javascript in question has an
>>> incredibly high likelihood of coming from the same place as the video
>>> itself so can be tailored to the situation.
>>> 
>>> It strikes me that DRM issues are not in principle any different in
>>> handling to unknown wrapper formats or codecs. There's _already_ a
>>> mechanism ‹ canPlayType() ‹ which can accept any arbitrary MIME type and
>>> return a value indicating whether the UA believes it can play it or not
>>> (and later, if it attempts to, tell you whether it really did manage to).
>>> 
>>> In short: why define a new API (or worse, set of APIs) when the existing
>>> mechanism does exactly what is required?
>> 
>> 
>

Received on Thursday, 1 September 2011 19:39:29 UTC