Re: [MEDIA_PIPELINE_TF] Content protection proposal

I made changes to "bits/second," but now I'm not sure I should have. We
talk about "bit rate" and most everything I've seen in other contexts uses
bits/second, but it appears that the Flash APIs use bytes/second.

Is there a common convention here? If not, I recommend bits/second since
that is how the data rate is typically specified in the digital television
and data access universes.

Thanks,
-Clarke

On 12/15/11 11:10 PM, "Clarke Stevens" <C.Stevens@CableLabs.com> wrote:

>I just sent it 2 seconds before I got this message. However, I'll comment
>on your recommendations below.
>
>-Clarke
>
>On 12/15/11 10:47 PM, "Mark Vickers @ Comcast"
><Mark_Vickers@cable.comcast.com> wrote:
>
>>Minor edits:
>>> http://www.w3.org/2011/webtv/wiki/MPTF/HTML_Error_codes
>>> 
>>>http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Minimal_Control_Model_Proposa
>>>l
>>
>>Minimal Control Model needs explanation. Perhaps copy explanation of the
>>three models into this doc or link back to other doc.
>
>I did include a link back to the architectural models (although it is
>towards the end of the message).
>
>>
>>Shouldn't bytes/second should be bits/second. Was this discussed? The SVG
>>API and other IETF APIs are bits/second.
>
>Since the message includes on links to the wiki, I can check and make the
>change (if necessary) on this. I agree that it should be bits per second.
>
>>
>>> http://www.w3.org/2011/webtv/wiki/MPTF/Netflix_Content_Protection
>>
>>May need to be some mention that there hasn't been time for full review
>>by or consensus of MPTF yet.
>
>We must be on the same wavelength. That's exactly what I did.
>
>>
>>Where do we reference the seamless playback use case and API?
>
>It's not referenced in the current response since we don't really have
>anything to link to yet. I still have an hour if we want to try to put
>something together. Would we link it to the same two bugs as the other
>proposals (parameters and feedback)? I'm not sure that was specifically
>requested from any particular bugs like the other proposals were.
>
>>
>>Thanks,
>>mav
>>
>>On Dec 15, 2011, at 9:12 PM, Clarke Stevens wrote:
>>
>>> I'm starting my final edits now and will send in the proposals shortly.
>>> Last call for changes or comments.
>>> 
>>> -Clarke
>>> 
>>> On 12/15/11 9:19 PM, "Mays, David" <David_Mays@comcast.com> wrote:
>>> 
>>>> I'm ok with the changes. Did you submit yet?
>>>> 
>>>> Dave
>>>> 
>>>> ________________________________________
>>>> From: Clarke Stevens [C.Stevens@CableLabs.com]
>>>> Sent: Thursday, December 15, 2011 5:08 PM
>>>> To: public-web-and-tv@w3.org WG
>>>> Subject: Re: [MEDIA_PIPELINE_TF] Content protection proposal
>>>> 
>>>> Although we have not really had a chance to review it as a group, I am
>>>> considering providing Mark Watson's content protection proposal as
>>>> feedback to the HTML WG in addition to the HTML Errors and ABR Minimal
>>>> Control proposals.
>>>> 
>>>> My motivation is that same as that for the ABR Minimal Control
>>>>proposal.
>>>> It is a useful and well-considered proposal that may require some
>>>> modification, but it provides a basis for discussion and a path for
>>>> inclusion in HTML5.
>>>> 
>>>> In other words, our feedback on LC Bugs 13625 and 12399 that is due
>>>>today
>>>> would include HTML Errors, ABR Minimal Control and Netflix Content
>>>> Protection:
>>>> 
>>>> http://www.w3.org/2011/webtv/wiki/MPTF/HTML_Error_codes
>>>> 
>>>>http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Minimal_Control_Model_Propos
>>>>a
>>>>l
>>>> http://www.w3.org/2011/webtv/wiki/MPTF/Netflix_Content_Protection
>>>> 
>>>> I plan to send this feedback to HTML WG this evening after people have
>>>> had a chance to comment, edit, etc.
>>>> 
>>>> Let me know what you think.
>>>> 
>>>> Thanks,
>>>> -Clarke
>>>> 
>>>> P.S. For your convenience, here are the links to the relevant bugs:
>>>> 
>>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13625
>>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=12399
>>>> 
>>>> 
>>> 
>>> 
>>
>
>

Received on Friday, 16 December 2011 06:21:06 UTC