Re: [MEDIA_PIPELINE_TF] Updated TPAC slides

A MIME type can indicate a DRM-protected stream using a particular codec. There's no new API needed for that. It can be handled by regular CanPlayType.

On Oct 27, 2011, at 9:53 PM, Clift, Graham wrote:

> I was not suggesting that all drm schemes need to be supported, only that a simple error mechanism could be utilized to detect support from transport layer up to application. CanPlayType might be extended as well to indicate through the type attribute whether the scheme is supported generally whereas transport layer protocols like http head parameters is the correct place to implement the scheme in full.
> 
> I'm just not clear why application level actions are needed on the user agent for what is essentially a transport mechanism.
> 
> Graham
> 
> ----- Original Message -----
> From: Vickers, Mark <Mark_Vickers@cable.comcast.com>
> To: Mark Watson <watsonm@netflix.com>
> Cc: Clift, Graham; C.Stevens@CableLabs.com <C.Stevens@CableLabs.com>; public-web-and-tv@w3.org <public-web-and-tv@w3.org>
> Sent: Thu Oct 27 21:37:53 2011
> Subject: Re: [MEDIA_PIPELINE_TF] Updated TPAC slides
> 
> That makes sense. Can you propose changes to the slides?
> 
> 
> 
> On Oct 27, 2011, at 8:51 PM, "Mark Watson" <watsonm@netflix.com> wrote:
> 
>> 
>> On Oct 27, 2011, at 7:48 PM, Clift, Graham wrote:
>> 
>>> Has anyone identified an actual parameter that needs passing to the video tag for the purpose of content protection? My understanding is currently content protection can be fully supported by transport layer protocols and that maybe support for some error handling messages is all that is needed.
>> 
>> This would be a very poor solution, IMO. This requires duplication of service-provider business logic and authentication in each DRM system and requires service providers to stand up multiple front-end DRM-specific servers (because we can't dictate all devices to support a single DRM).
>> 
>> What we proposed back in February was that applications should be able to discover the available DRM mechanisms and mediate the key exchange. This allows authentication and authorization to be done where it belongs at the service layer and reduces the functionality expected of the DRM.
>> 
>> ...Mark
>> 
>>> I understand that future content protection schemes may need additional application level parameter passing but without an exact definition we're back to the generic param that no one wants.
>>> 
>>> 
>>> Graham Clift
>>> 
>>> ----- Original Message -----
>>> From: Vickers, Mark <Mark_Vickers@cable.comcast.com>
>>> To: Mark Watson <watsonm@netflix.com>
>>> Cc: Clarke Stevens <C.Stevens@CableLabs.com>; public-web-and-tv@w3.org <public-web-and-tv@w3.org>
>>> Sent: Thu Oct 27 19:10:26 2011
>>> Subject: Re: [MEDIA_PIPELINE_TF] Updated TPAC slides
>>> 
>>> Mark,
>>> 
>>> It's important for ISSUE-179 (bug 13333) to be included on all those pages because that is the bug that gives these media parameter/error requirements LC1 status. The bug raised in 179/13333 is that there are several missing parameters for media, including specific examples of adaptive streaming, content protection and UPnP streaming. You don't have to agree with the bug submitter's proposed solution of an arbitrary parameter mechanism. In fact, the discussion invites an alternative to arbitrary parameters:
>>> 
>>>> If you believe there are other parameters that should be standardised (as you seem to indicate), then you should take each and every one of them forward for standardization. [1]
>>> 
>>> 
>>> This is what we're doing on R7, R8, R10 and R11. We are bringing forward parameters that we think should be standardized.
>>> 
>>> We need to put 179/13333 back in the bug list for all four pages, because they are all the suggested alternative solution of specific parameters to that LC1 bug. 
>>> 
>>> Note: In none of the page's "Suggested changes" is there a suggestion for arbitrary parameters. But as alternative solutions to 179/13333, they are all legitimately LC1.
>>> 
>>> I hope you can agree to adding back 179/13333 to the bug lists. OK?
>>> 
>>> Thanks,
>>> mav
>>> 
>>> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333#c9
>>> 
>>> 
>>> On Oct 27, 2011, at 5:06 PM, Mark Watson wrote:
>>> 
>>>> Hi Clarke,
>>>> 
>>>> Thanks for making the changes. I still think that ISSUE-179 should be removed from the rows for the Content Protection-related items on the last-but-one page: I don't agree that this is the solution for Content Protection.
>>>> 
>>>> As discussed on the call, I don't think the argument that because the existing plug-in mechanism (<object>) allows arbitrary parameters to be passed to the plugin then <video> should also allow arbitrary parameters holds any water. These things are completely different: video is (currently) a function fully provided by the browser, whereas plugins are not.  Hence there is nowhere to pass these arbitrary parameters to in the <video> case ... today. <object> is a mechanism for arbitrary plugins which might provide any kind of capabilities, not just video, and this also weakens the comparison.
>>>> 
>>>> What is implied by the ISSUE-179 is introduction of a new plugin architecture that enables dynamic extensions to the <video> element. That may be a good thing, but you have to start by proposing that change, not with a (relatively minor) technical consequence of that change.
>>>> 
>>>> Regarding Content Protection, this is a capability which the browser may have that should have its own methods for discovery (by Javascript) and key exchange. Whether the capability is provided by the browser, by some hardware component that the browser can connect to, or by a plugin shouldn't affect any content-protection related APIs on the video element.
>>>> 
>>>> ...Mark
>>>> 
>>>> 
>>>> On Oct 27, 2011, at 3:25 PM, Clarke Stevens wrote:
>>>> 
>>>>> I made changes to the slides based on feedback during the meeting and some
>>>>> emailed comments afterwards. Please let me know of any other suggested
>>>>> changes.
>>>>> 
>>>>> Thanks,
>>>>> -Clarke
>>>>> 
>>>>> 
>>>>> <W3C MPTF Requirements-v9.ppt>
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>

Received on Friday, 28 October 2011 18:13:09 UTC