Re: [MEDIA_PIPELINE_TF] Meeting Announcement

FYI: on R8, you might want to mention
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12399 because it already
asks for specific delivery statistics.

Incidentally, if that wasn't clear, I agree with Mark that ISSUE-179
with a request for a param element is not a solution to the problems
at hand and suggestion of concrete attributes that should be added
would be more productive.

Best Regards,
Silvia.


On Fri, Oct 28, 2011 at 3:38 AM, Mark Watson <watsonm@netflix.com> wrote:
> Clarke,
>
> Unfortunately I did't have the slides in front of me during the call and now I look I have a few comments:
>
> On slide 5 (R8):
> 1) The requirement for better error reporting is not restricted to adaptive streams - various kinds of network errors (DNS, IP, TCP, TLS) can happen with any kind of media playback
> 2) I don't see the connection with ISSUE-179 - additional errors and statistics should be generic and defined in HTML, not through any kind of param mechanism
>
> I'd suggest changing the title to "Additional Media Errors", removing the reference to ISSUE-179 and adding some examples, such as
>
> Errors: DNS failures, TCP failures, TLS failures
> Events: change in rendered stream (for adaptive bit rate)
>
> On slide 6 & 7 (R10, R11):
> 1) Again I don't see the connection with ISSUE-179. What we need is a way defined in HTML that provides specific capabilities for communicating with the DRM agent, not just a general-purpose extensibility mechanism. When did we agree that the param mechanism was the desired solution to content protection in HTML5 ?
>
> I'd suggest removing the reference to the ISSUE and bug from this slide.
>
> On Slide 7 (R11): For our part (Netflix) we think authorization in the HTML video context should be handled by the service, not the DRM agent: we want to implement our business logic once in a way that is independent of the DRM. So this would mean the examples given are not needed. The kind of error you get would be at the level of a key exchange failure. I think the examples will be a red flag to some.
>
> On Slide 8: Please remove the ticks under ISSUE-179 from R8, R9, R11 and the tick under Bug-13625 for R10.
>
> On Slide 9, I think you'll get a very negative response to the first bullet. I don't think people see it as their job to provide technical solutions to other people's requirements. If we say "accept our proposals or propose a different solution" I expect the response to be "No, we're rejecting your proposals for x, y, z reasons, please come back with better ones". A better request would be "Assistance from HTML group in developing solutions to these requirements in HTML".
>
> ...Mark
>
>
>
>
> On Oct 27, 2011, at 7:38 AM, Clarke Stevens wrote:
>
>> Here's the slide deck I plan to present at TPAC. We'll review this today.
>>
>> -Clarke
>>
>>
>>
>> On 10/26/11 5:08 PM, "Clarke Stevens" <C.Stevens@CableLabs.com> wrote:
>>
>>> Here's the proposed agenda for the MPTF meeting:
>>>
>>> http://www.w3.org/2011/webtv/wiki/MPTF/Agenda_Telco_27th_October_2011
>>>
>>> Here's the meeting information:
>>>
>>> http://www.w3.org/2011/webtv/wiki/MPTF/Telco
>>>
>>>
>>> Thanks,
>>> -Clarke
>>>
>>>
>>
>> <W3C MPTF Requirements-v8.ppt>
>
>
>

Received on Friday, 28 October 2011 05:08:49 UTC