Rgd CMAF in Dash

[Romain Picard]

> Le 6 avr. 2017 à 17:54, Nicolas Dufresne <nicolas at ndufresne.ca> a écrit :
> 
> Le jeudi 06 avril 2017 à 19:21 +0530, Sanjay Gupta a écrit :
>> Hi,
>> 
>> do gstreamer already have changes in dash based on CMAF
>> specification?
>> 
> 
> I wasn't aware, neither I'm involved, but isn't CMAF moving stuff from
> DASH into HLS, leaving DASH as-is ? I was reading this.
> 
> https://blogs.akamai.com/2016/06/cmaf-what-it-is-and-why-it-may-change-
> your-ott-future.html
> 
> I believe there is nothing new that were not support into dash. From
> there, enabling fmp4 from HLS should be fairly straightforward. There
> might be new things to parse in the .m3u8 files, but nothing major.

A nice Introduction on CMAF from Cyril 	Concolato is available here:
https://www.slideshare.net/EricaBeavers/cmaf-101-by-cyril-concolato <https://www.slideshare.net/EricaBeavers/cmaf-101-by-cyril-concolato>

CMAF is basically isobmff with extensions. It does not cover the manifest part. When Cyril presented this I noted some differences with what exists in DASH today:

- The initialization segment is in a CMAF header.
- CMAF defines tracks as a list of segments
- low latency is done in a different way than in dash: Dash uses http 1.1 chunk mode to allow the client to start retrieving a segment that is not yet fully available while CMAF splits a segment in smaller « chunks » that are served with http 1.0 (The name will probably bring confusion with http chunk mode).

So there will be evolutions needed on qtdemux to support these, but this will come with a manifest/standard using these new CMAF parts.

Romain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170409/e932c08e/attachment.html>