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 Tuesday, 13 December 2011 18:18:03 UTC