Re: HTTP Live Streaming: IETF draft from Apple

Raphael,
I noticed your question below on Smooth Streaming, and think you'll find some answers here:
http://blogs.iis.net/chriskno/archive/2009/09/08/smooth-streaming-specifications-now-posted-on-line.aspx

The blog contains links to a couple specs Microsoft just published under "Community Promise", which offers them royalty free, etc. (as far as Microsoft is concerned).

One is a "fragmented" version of the ISO Base Media File container called "PIFF", with an example AVC Track, and encryption methods, etc. to support multiple DRM systems using the same file.  (PIFF = Protected Interoperable File Format)  DRM interop and adaptive streaming are the main features, but other goodness is inherited from the ISO file format or built on it.

The other spec is the Smooth Streaming protocol you were wondering about.

The Smooth Streaming protocol has been used by Microsoft IIS server for quite some time, but the application to an ISO file with AVC and PlayReady DRM is probably being demonstrated publicly for the first time at IBC right about now.  Other DRMs could unlock the same files, but we aren't demonstrating that at IBC.

Regarding the issue of using a URL fragment to request an ISO Movie Fragment:  That makes a lot of sense, but there are some tradeoffs.

The Smooth Streaming protocol downloads a manifest that contains a time and track index of the ISO Tracks available for streaming.  It uses SMIL syntax as you said.  If a client is smart enough to parse it, it can issue a HTTP:GET(byteRange) requests to a fairly stupid HTTP 1.1 server to do adaptive bitrate streaming, resolution selection, language Track selection, accessibility Track selection, etc.  Tracks can be independently switched on the fly (you don't need a separate muxed file for each different Track combination, which is the case if you hack up perfectly good files into little pieces at video entry points while turning all other tracks and system information into collateral damage).  Tracks can be stored in separate files.  The Klingon audio track can be added at any time by copying the file and adding it to the index/manifest.

If a URL syntax was used to request Movie Fragments from different video Tracks and audio Tracks and Subtitle Tracks based on bitrate, language, codec, resolution, etc., then the server would have to be much smarter to use Track metadata, the 'mfra' (Movie Fragment Random Access) and 'tfra' (Track Fragment Random Access) Boxes in the ISO file to resolve those URL requests to byte offsets.  Nice for dumb client devices, but increases server requirements.

Kilroy Hughes
Microsoft Entertainment and Devices Division
Policy and Standards

<RT>

It seems that nearly one year ago, Microsoft proposed an approach for

adaptive video streaming over HTTP named Smooth Streaming but that they

didn't submit this technology standard to IETF to make it RFC. Apple's

submission seems to be similar, though the spec proposes to extend M3U

while Microsoft's proposal was based on SMIL. To learn more about the

Live Smooth Streaming for IIS 7.0, see [4,5]. The blog post [6] is also

worth to read.



The general idea is that IIS Smooth Streaming extension just maps URL to

a chunk in a file. So, when receiving a request for the following URI:

http://test.ru/mov.ism/QualityLevels(400000)/Fragments(video=61024)

the IIS Smooth Streaming extension checks "mov.ism" manifest file to

find filename of the file with requested quality level (400000), opens

and parses this file to get the chunk with requested time offset

(61024). Then this chunk is returned in a normal HTTP response.



I have no idea of how often the IIS Smooth Streaming extension is used

and deployed and whether "fragments" are actually requested this way.



Question 2: Should we ask Microsoft or do you think it will be the kind

of information the company is not willing to provide publicly?

</RT>