W3C home > Mailing lists > Public > public-web-and-tv@w3.org > December 2011

RE: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur

From: Jan Lindquist <jan.lindquist@ericsson.com>
Date: Tue, 13 Dec 2011 18:31:20 +0100
To: Mark Watson <watsonm@netflix.com>, David Mays <David_Mays@Comcast.com>, "public-web-and-tv@w3.org WG" <public-web-and-tv@w3.org>
Message-ID: <82276AE38FD87A4C9CF6C820AC5276EA358FBF235E@ESESSCMS0362.eemea.ericsson.se>
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.
Received on Tuesday, 13 December 2011 17:31:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:06 UTC