[whatwg] A standard for adaptive HTTP streaming for media resources

[Silvia Pfeiffer]

On Tue, May 25, 2010 at 1:40 PM, Chris Holland <frenchy at gmail.com> wrote:
>
>
>> * authoring of content in a specific way
>> * description of the alternative files on the server and their
>> features for the UA to download and use for switching
>> * a means to easily switch mid-way between these alternative files
>
> I don't have something decent to offer for the first and last bullets but
> I'd like to throw-in something for the middle bullet:
>
> The http protocol is vastly under utilized today when it comes to URIs and
> the various Accept* headers.
>
> Today developers might embed an image in a document as chris.png. Web
> daemons know to find that resource and serve it, in this sense, chris.png is
> a resource locator.
>
> Technically one might reference the image as a resource identifier named
> "chris". The user's browser may send  "image/gif" as the only value of an
> accept header, signaling the following to the server: "I'm supposed to
> download an image of chris here, but I only support gif, so don't bother
> sending me a .png". In a perhaps more useful scenario the user agent may
> tell the server "don't bother sending me an image, I'm a screen reader, do
> you have anything my user could listen to?". In this sense, the document's
> author didn't have to code against or account for every possible "context"
> out there, the author merely puts a reference to a higher-level
> representation that should remain forward-compatible with evolving servers
> and user-agents.
>
> By passing a list of accepted mimetypes, the accept http header provides
> this ability to serve context-aware resources, which starts to feel like a
> contender for catering to your middle bullet.
>
> To that end, new mime-types could be defined to encapsulate media type/bit
> rate combinations.
>
> Or the accept header might remain confined to media types and acceptable bit
> rate information might get encapsulated into a new header, such as:
> X-Accept-Bitrate .


That's not quite sufficient, actually. You need to know which byte
range to retrieve or which file segment. Apple solved it by
introducing a m3u8 file format [1], Microsoft by introducing a
SMIL-based server manifest file [2], Adobe by introducing a XML-based
Flash Media Manifest file F4M [3]. That kind of complexity canot
easily be transferred through HTTP headers.

[1] http://developer.apple.com/iphone/library/documentation/networkinginternet/conceptual/streamingmediaguide/HTTPStreamingArchitecture/HTTPStreamingArchitecture.html
[2] http://msdn.microsoft.com/en-us/library/ee230810(VS.90).aspx
[3] http://opensource.adobe.com/wiki/display/osmf/Flash+Media+Manifest+File+Format+Specification


> If you combined the above approach with existing standards for http byte
> range requests, there may be a mechanism there to cater to your 3rd bullet
> as well: when network conditions deteriorate, the client could interrupt the
> current stream and issue a new request "where it left off" to the server.
> Although this likel wouldn't work because a byte range request would mean
> nothing on files of two different sizes. For playbacked media, time codes
> would be needed to define range.

The idea of the manifest file is to provide matching transition points
between the different files of different bitrate to segments or byte
ranges. This information has to somehow come to the UA (amongst other
information as available in typical manifest files). I don't think
that can be achieved without a manifest file.

Cheers,
Silvia.