Re: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur

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.

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.

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.
* AdaptationSetChanged - The media has entered a different period where
the set of Representations may differ.


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 15:59:44 UTC