Re: [MEDIA_PIPELINE_TF] Content protection proposal

bits/second or bytes/second doesn't matter. The issue is that unless you specify a time period (or more generally an averaging algorithm) the measure is meaningless. I'm aware that there are existing APIs where no time period is specified, but this just means it is implementation-specific. That might be ok when there is only one implementation, because people learn by experimentation what that one implementation does. For example there is only one implementation of Flash and only one of Silverlight. But if you want to write something meaningful that could support multiple interoperable implementations, you need to be more specific.

...Mark

On Dec 15, 2011, at 10:20 PM, Clarke Stevens wrote:

> 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:48:19 UTC