Re: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur

On Dec 12, 2011, at 7:58 AM, Mays, David wrote:

> 
> 1. I believe that as segment is used in the current document, it is
> referring to a discrete chunk of a media track (or Representation in
> MPEG-DASH). I would refer to the MPEG-DASH definition of segment.

A segment in MPEG DASH refers (roughly) to a file stored on the server. In the On Demand profile there is a single segment for each  bitrate.

> 
> 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).

The attributes in HLS, Smooth Streaming and DASH likely have different definitions.

We need to take a step back here and understand the requirements: why do we want scripts to have control of these things and what kind of control to we want them to have ?

For example, if the requirement is to allow the service provider and/or user to limit bandwidth usage (because the user has a bandwidth cap or usage-based-charging), then the parameter should be a long-term limit on bandwidth used and what the client does to stick within that is up to the client implementation.

On the other hand, if the requirement is to allow service providers to experiment and differentiate with different adaptive streaming algorithms, we need to demonstrate that the proposed extensions actually allow that. In particular, the ability to set the stream choice from based only on a report of the incoming throughput enables experimentation with approximately one algorithm (i.e. it doesn't really allow any interesting experimentation.

In my view, to meet the second requirement means that, at a minimum, the script needs to have
(1) fine-grained visibility of the network performance: bytes received at a small reporting granularity <500ms, TCP connect times, HTTP response times
(2) visibility of the available streams and their bitrate profile over time (VBR profile)
(3) visibility of the multiple possible locations at which each stream is available
(4) visibility of client buffers: received data, requested but not received data
(5) notification of the appropriate decision points (in time)
(5) control of the choice of stream and of choice of download location at those decision points

Constructing a Javascript API for this is complex. I think a more realistic approach to providing this possibility for experimentation and differentiation is approach 3.

> 
> I will note that in DASH, because of the extra complexity/flexibility of
> the model, different "periods" within a piece of media may have different
> "adaptation sets" each having different lists of available bandwidths, the
> programming model we are discussing here could have some issues if, for
> example, a period within a DASH media had a higher minimum bandwidth than
> what the application specified, based on the initial set of available
> quality levels.
> 
> I would say this could even happen with other forms of adaptive streaming,
> in a "live linear" scenario where a broadcaster decided during part of a
> stream to downgrade the overall quality of the stream (e.g. For low-cost
> advertising, etc) and the highest available quality level was lower than
> the minimum specified by the application.
> 
> Overall that seems like an application concern, though it might make sense
> to have some form of notification to an application that the set of
> quality levels has changed.
> 
> Would there be an error case here if the either the minLevel or maxLevel
> that was set was "out of bounds"?
> 
> 3. I assume you are using the DASH definition of Representation here. It
> seems like there are a handful of useful notifications that are not in
> this proposal yet:
> 
> These are based on definitions from MPEG-DASH, but could be mapped onto
> similar concepts in other streaming schemes.
> 
> * RepresentationChanged - The adaptive heuristic algorithm has caused the
> player to switch to a different representation.

This is definitely needed in approaches 1 and 2 for reporting. The event should be based on the actual change of rendered Representation, not on the decision.

Rather than use bitrate/bandwidth as a tag for the Representation, we should ask each adaptive streaming system to nominate an appropriate "id" field. DASH has one. For HLS one might use the playlist name. I think this makes it clear that the naming scheme is system-specific and avoids confusion about the meaning of bitrate/bandwidth fields.

> * AdaptationSetChanged - The media has entered a different period where
> the set of Representations may differ.

This might be better called PeriodChanged.

> 
> 
> David Mays | sr. software architect | 15.217 | one comcast center |
> philadelphia, pa. 19103 | 215.286.3395 w | 215.847.9631 m
> ---------------------------------------------------------------------------
> -------------------------------------------------------------
> 
> 
> 
> 
> On 12/12/11 3:33 AM, "Jan Lindquist" <jan.lindquist@ericsson.com> wrote:
> 
>> Hello,
>> 
>> I have a couple of questions on the proposal.
>> 
>> 1. segment definition
>> Can a definition of segment be added to the proposal? It will help go
>> over the below comments.
>> 
>> 2. maxLevel (input)
>> What is the format of the input. Is it a segement identifier or
>> bandwidth? If it is agreeable I would recommend to adopt concept of
>> bandwidth that is mapped to the manifest bandwidth. Even though the
>> bandwidth is a subjective level based on what is reported in the manifest
>> rather than actual it is the best form to indicate a max limit. An extra
>> argument could also be included indicating what position that this max
>> level should be applied. An issue for implementers is that simply
>> indicating max level may have different effects depending on how the
>> buffer is handled. If this can be done at a future position it will make
>> for a smoother transition.
>> 
>> 3. callback change in representation
>> I am missing a callback reporting when the representation has changed. It
>> might be what is called segment in the proposal but I am not sure. This
>> callback is only reported when the "bandwidth" has changed. The
>> "position" at which this change occurs should also be included since it
>> may occur in a future point.
>> 
>> Regards,
>> JanL 
>> 
>> -----Original Message-----
>> From: Clarke Stevens [mailto:C.Stevens@cablelabs.com]
>> Sent: den 9 december 2011 20:01
>> To: public-web-and-tv@w3.org
>> Subject: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur
>> 
>> Please take a look at the Wiki page for Adaptive Bit Rate.
>> 
>> http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Error_Codes
>> 
>> I'd like to have a good list of parameters, and errors (for model 1 in
>> particular) that we can provide for MPTF folks to review over the next
>> view days. You can make suggested edits directly, or post your ideas to
>> the reflector.
>> 
>> Also, please make sure we are in agreement on the definitions of the
>> architectural models.
>> 
>> Thanks,
>> -Clarke
>> 
>> 
>> 
> 
> 
>

Received on Monday, 12 December 2011 17:20:10 UTC