RE: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architecture

Can't any API have defaults and set ranges of values in the plain vanilla usage of that API but also have an escape mechanism which would allow a developer or content provider/owner to step out of those bounds for special purposes? This way, no one is limited inherently but suggested best settings and ranges are available. It's likely that these parameters and values will need to be modified and/or augmented over time.

Thanks!
-Paul

Q me



-----Original Message-----
From: Jan Lindquist [mailto:jan.lindquist@ericsson.com] 
Sent: Wednesday, December 14, 2011 2:57 AM
To: Mark Watson
Cc: David Mays; public-web-and-tv@w3.org WG
Subject: RE: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur

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?

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 Thursday, 15 December 2011 15:41:47 UTC