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

Re: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur

From: Vickers, Mark <Mark_Vickers@cable.comcast.com>
Date: Thu, 15 Dec 2011 22:11:01 +0000
To: Mark Watson <watsonm@netflix.com>
CC: "Mays, David" <David_Mays@Comcast.com>, Clarke Stevens <c.stevens@cablelabs.com>, Duncan Rowden <duncan.rowden@bbc.co.uk>, Jason Lewis <jason.lewis@disney.com>, 이현재 <hj08.lee@lge.com>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Message-ID: <25565998-C662-4AB2-A4BE-BFCFE0D8B5AE@cable.comcast.com>
FYI, the only other W3C spec I can see that has a bandwidth parameter is SVG Tiny 1.2 [1]. It's in bits/second, but I don't see any definition of the measurement time period here, either.

Perhaps for today we can just specify the same as this and add a note that the time period for this measurement is an issue TBD.

mav

[1] http://www.w3.org/TR/SVGTiny12/single-page.html#struct-PrefetchElementBandwidthAttribute



On Dec 15, 2011, at 11:31 AM, Mark Watson wrote:


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




Received on Thursday, 15 December 2011 22:11:57 UTC

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