Re: [MEDIA_PIPELINE_TF] Common content security requirements

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:01:58 UTC