Re: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur

On Dec 13, 2011, at 11:56 PM, Jan Lindquist wrote:

> Hi Mark,
> 
> We may be complicating the question of quality or bit-rate levels. The solution I was looking for was specifically tied to the manifest and not the UA available bit-rate speeds. That will be difficult for reasons you have explained. I am assuming the UA has to have some means to understand the available segments and what level they fall under. A UA will not experiment with downloading all segments to then determine which bit-rate they fall under.
> 
> Can we agree that the level is associated to the manifest independent of actual bit-rate?

In this case the Javascript has to know about the manifest. And then I would argue you should be following Model 3.

In my view, it is far too early for us to think we can design the correct functional split between Javascript and UA for Model 2. I have not seen any proposals which meet the requirement of allowing interesting differentiation and experimentation. We should develop model 3 and experiment with this. As a result of that experimentation we might have more insight into how to design Model 2.

So I think we should take model 2 off the table for the moment.

This is not to say we shouldn't address the requirements for user limiting of bandwidth usage, but this is more under model 1 than 2 and then these are real long-term bandwidth figures unrelated to the streams in the manifest.

...Mark

> 
> Just to clarify if the actual bit-rate is lower than the selected max level then UA will perform best effort and select the segement suited for viewing below the level. If min level is set then there may be issues with buffering and pausing of the video rendering.
> 
> Regards,
> JanL
> 
>> -----Original Message-----
>> From: Mark Watson [mailto:watsonm@netflix.com] 
>> Sent: den 13 december 2011 19:17
>> To: Jan Lindquist
>> Cc: David Mays; public-web-and-tv@w3.org WG
>> Subject: Re: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur
>> 
>> 
>> On Dec 13, 2011, at 9:31 AM, Jan Lindquist wrote:
>> 
>>> Hello,
>>> 
>>> A couple of comments below reflecting some changes I made 
>> to the draft.
>>> 
>>> Regards,
>>> JanL
>>> 
>>>> 
>>>>> 
>>>>> 2. The input value here could vary depending on the underlying 
>>>>> representation of "quality level" within the manifest or playlist.
>>>>> - In the case of HLS, each quality level is represented by 
>>>>> BANDWIDTH=nnnnnn
>>>>> - In Smooth Streaming, each <QualityLevel> element contains
>>>> a Bitrate
>>>>> attribute
>>>>> - In MPEG-DASH, each <Representation> element has a bandwidth 
>>>>> attribute
>>>>> 
>>>>> So for three major forms of adaptive streaming, it seems as
>>>> though a
>>>>> direct reference to the "bitrate" or "bandwidth" number 
>> makes sense 
>>>>> here as the input value.
>>>> 
>>>> It's meaningless to describe bitrate or bandwidth with a single 
>>>> number, unless you are talking about a very long-term average. 
>>>> Bandwidth is not like velocity, which varies continuously and 
>>>> therefore has a meaningful value at a single point in 
>> time: you need 
>>>> to specify what kind of average you are talking about (for 
>> example, 
>>>> over what time period).
>>>> 
>>> 
>>> What I am after that we agree on a "level" indication if that is
>>> - bandwidth
>>> - quality
>>> - bitrate
>>> - or other
>>> 
>>> I made a small change to the first sentence in maxLevel to 
>> specific "maximum quality or bitrate level" instead of 
>> "maximum streaming level" to be consistent with minLevel.
>>> 
>> 
>> I think it's a very different thing to have the API control 
>> the maximum bandwidth that the player should use (for example 
>> for users to reduce usage-based charging or manage data caps) 
>> vs controlling which of a set of "representations" should be used.
>> 
>> The former is simple: we just specify a long term maximum on 
>> the bandwidth used in kbit/s. The player should not use more 
>> than that amount of bandwidth (over time), but there is no 
>> direct implication about which of the available bitrates it 
>> may choose (in particular, if I specify a max bandwidth of 
>> 2Mbit/s this would not prevent the player from picking some 
>> stream labeled 2.1Mbit/s for a while, if picking that stream 
>> for that length of time did not result in more than 2Mbit/s 
>> of data arriving, on average).
>> 
>> The latter is much more complex, requiring exposing to the 
>> Javascript of many details about the available streams. I do 
>> not think we should attempt it now and should focus on Method 3.
>> 
>> ...Mark
>> 
>>> 
>>> 
>> 
>>

Received on Wednesday, 14 December 2011 16:51:57 UTC