[foms] Proposal: adaptive streaming using open codecs

[Mark Watson]

On Nov 16, 2010, at 1:49 PM, Jean-Baptiste Kempf wrote:

On Tue, Nov 16, 2010 at 07:29:21PM +0100, Pierre-Yves KEREMBELLEC wrote :
- JSON for all manifest files (as it's easy to parse on any platform and heavily extensible)

I disagree. Most software and hardware media players don't have any JSON
code-related already.

How is JSON so much better than XML?
Many playlists are already XML based, I don't see where is the need to
impose yet another format to parse to them?

What is more important than the specific syntax (JSON, XML, M3U8 etc.) is the data model or abstract syntax. Once you have that you can map pretty easily to any specific syntax. It would be good to discuss what is needed at that level first.

Roughly, something like the following:
- some notion of <track> which is composed of one or more <stream>s (the specific terms can be changed).
- A <track> is a single media type or interleaved combination of multiple types. The <stream>s it contains are different encodings of the exact same source media (so different audio languages are different <tracks>). If the <track> contains multiple media types every <stream> has all those media types interleaved i.e. all <stream>s contained interleaved media or no <stream>s contain interleaved media within a <track>. In the second case all the <stream>s in the track contain the same single media type.
- a way to annotate both <track>s and <stream>s with their properties for selection purposes: file format, media type(s), codecs/profiles, language, video resolution, pixel aspect ratio, frame rate, bandwidth, accessibility type (e.g. audio description of video, sign language) or other track type info (e.g. directors commentary) (Maybe this is too many, but annotations like this are cheap - clients just ignore tracks with annotations they do not understand). If all the <stream>s in a track have the same value for an annotation then you can annotate the <track> otherwise annotate the <stream> (that is just an optimization).
- access information for each <stream>. EITHER
(i) a URL for a single file containing the whole stream, including stream headers and an index, OR
(ii) a URL for the stream headers and a list of URLs for the chunks and timing information for the chunks (could be constant chunk size)
By stream headers I mean initialization information that applies to the whole stream.

Some additional details:
- we've discussed various ways that chunks (however obtained) are aligned/can be concatenated or not. Additional <track> annotations are needed (IMO) to tell the player what properties the streams have in terms of chunk alignment, RAP positions etc. (Compatibility in terms of codecs etc. should be clear from the annotations)
- you might want to use templates instead of long URL lists (as per another mail thread). If you do use long URL lists, you might want to be to store them in a separate files ("submanifests").
- wherever a URL appears, it's useful (and for our service essential) to be able to provide a list of alternative URLs (in the same way DNS provides a list of alternative IP addresses). We use this for redundancy across CDNs.
- how you find the headers and index in case (i) and their format may be file format dependent.
- if the group wants to choose a single option between (i) and (ii) then I would obviously recommend (i). But you might want to include both options.
- content protection is a whole big topic which may not be of so much concern to this group. But the manifest aspects can be handled easily with additional annotations.

If there is support for this kind of "data model" approach, then I'd be happy to write up a more detailed proposal based on whatever discussion is triggered by the above.

...Mark


Best Regards,

--
Jean-Baptiste Kempf
http://www.jbkempf.com/
+33 672 704 734
_______________________________________________
foms mailing list
foms at lists.annodex.net
http://lists.annodex.net/cgi-bin/mailman/listinfo/foms


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.annodex.net/cgi-bin/mailman/private/foms/attachments/20101117/77e64249/attachment-0001.htm