[foms] Proposal: adaptive streaming using open codecs

[Frank Galligan]

On Wed, Nov 17, 2010 at 12:09 PM, Mark Watson <watsonm at netflix.com> wrote:

>
> 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.
>
[Frank]
I think this is good. I started working on a demo with a manifest file, but
I didn't correlate the streams from the same source like this. I just had
all the streams flat. I think what you proposed would work better.

- 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.
>
[Frank]
The manifest proposal I was writing has support for both. I think going
froward (i) is the best, but I added (ii) specifically to add support for
the possibility of stream switching audio seamlessly with files that have
already been encoded. As most of the current files only have aseek index for
video.

Overall I think this is a good overview of what a manifest should provide.


> - 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
>
>
>
> _______________________________________________
> 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/20101122/c9e5728c/attachment-0002.htm