Hi,
do gstreamer already have changes in dash based on CMAF specification? Thanks & Regards, Sanjay _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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. regards, Nicolas _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel signature.asc (188 bytes) Download Attachment |
Hi Nicolas, Actually I read this link and saw the following statement: "CMAF is very similar to the file container that DASH already uses today, so adopting CMAF from the DASH perspective requires little, if any, change to encoders, workflow or players." so thought to clarify with you guys if any additional changes will be require for this. Good to know that there will not be any changes required for this. Thanks for clarification. Thanks & Regards, Sanjay On Thu, Apr 6, 2017 at 9:24 PM, Nicolas Dufresne <[hidden email]> wrote: Le jeudi 06 avril 2017 à 19:21 +0530, Sanjay Gupta a écrit : _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Le jeudi 06 avril 2017 à 21:47 +0530, Sanjay Gupta a écrit :
> Actually I read this link and saw the following statement: > "CMAF is very similar to the file container that DASH already uses > today, so adopting CMAF from the DASH perspective requires little, if > any, change to encoders, workflow or players." > > so thought to clarify with you guys if any additional changes will be > require for this. > > Good to know that there will not be any changes required for this. > Thanks for clarification. is still work done on the core support every cycles. A sink that produce both DASH manifest and HLS m3u using CMAF storage would be nice. regards, Nicolas _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel signature.asc (188 bytes) Download Attachment |
In reply to this post by Nicolas Dufresne-5
A nice Introduction on CMAF from Cyril Concolato is available here: 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. _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |