Re: [MEDIA_PIPELINE_TF] Updated TPAC slides

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. 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 02:49:39 UTC