W3C home > Mailing lists > Public > public-web-and-tv@w3.org > September 2011

Re: [MEDIA_PIPELINE_TF] Common content security requirements

From: Mays, David <David_Mays@Comcast.com>
Date: Thu, 1 Sep 2011 15:44:38 +0000
To: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Message-ID: <CA852088.7FA6%David_Mays@Comcast.com>
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 15:45:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 1 September 2011 15:45:13 GMT