Re: [MEDIA_PIPELINE_TF] Common content security requirements

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>

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" <> 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 15:45:12 UTC