RE: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur

Maybe the  simplest solution is to specify bandwidth per second.

Bandwidth per second is bytes per second per second.

Then leave it to the UA implementation to assign a sensible averaging period (which doesn’t necessarily mean one second).

Regards

Graham Clift

From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Thursday, December 15, 2011 11:32 AM
To: Mays, David
Cc: Clarke Stevens; Duncan Rowden; Jason Lewis; 이현재; public-web-and-tv@w3.org
Subject: Re: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur


On Dec 15, 2011, at 10:08 AM, Mays, David wrote:


Yeah, I realized this after I did it. My apologies for any confusion it caused.

I've just done a bunch of editing, and made further use of the [initials] notation as well as text strikethrough.

I'm done with my edits for now, having added Silverlight information, as well as re-organizing the use cases, and  replacing the parameters with new ones to reflect the content of our discussions.

I think the startingPlaybackHint parameter could use a javascript "enum" like the following as its input, though ultimately it's just a primitive value being passed to the parameter. I prefer the use of an enum-like structure just for clarity.

AdaptiveHint = {
OptimizeForFastStart : 0,
OptimizeForHighQuality : 1
}

Please edit as needed.

Mark, can you offer comment on the proposed "bytes/second" unit of measure for bandwidth?

That's fine for the units, but we need to give some guidance as to timescale. The client can obviously exceed the limits on a short timescale (for example, whilst a packet is arriving on a 100baseT ethernet, the throughput is 100MBit/s and when no packet is arriving it's 0Mbit/s.). I'm not sure we can do better than to say that the client "should ensure that long-term throughput associated with the media element does not exceed the specified value.".

...Mark



Thanks,

Dave

David Mays | sr. software architect | 15.217 | one comcast center | philadelphia, pa. 19103 | 215.286.3395 w | 215.847.9631 m
----------------------------------------------------------------------------------------------------------------------------------------

From: Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>>
Date: Thu, 15 Dec 2011 17:45:46 +0000
To: David Mays <David_Mays@Comcast.com<mailto:David_Mays@Comcast.com>>
Cc: Clarke Stevens <c.stevens@cablelabs.com<mailto:c.stevens@cablelabs.com>>, Duncan Rowden <duncan.rowden@bbc.co.uk<mailto:duncan.rowden@bbc.co.uk>>, Jason Lewis <jason.lewis@disney.com<mailto:jason.lewis@disney.com>>, 이현재 <hj08.lee@lge.com<mailto:hj08.lee@lge.com>>, "public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>" <public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>>
Subject: Re: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur

Btw, as a procedural thing, I'm not sure how we should be using the wiki.

David responded to my comments by making changes to the original text, so now my comments don't make any sense to a new reader (because the original, commented on, text is gone). This is not good for people wanting to follow the discussion.

Either we should use the "talk" page, or responses/counter-proposals should be inline under the comments they are in response to.

...Mark