gpac
gpac copied to clipboard
Add Support to SCTE - 35
Hi, Do you have in your roadmap add support to SCTE-35? If not.... I can do it, but maybe I need help to know the project structure.
Thanks and awesome project!
I have on my plate to extract the SCTE-35 markers from MPEG-TS and forward them to the DASH/HLS muxer.
Which use-cases do you want to cover?
Exactly that one! also I start to code that!
But i have a lot of problems/questions regarding the arch of the project
The first step is to demux the messages. You'll need to modify a bit the M2TS demuxer code :
- add SCTE35 PID in gf_m2ts_process_pmt
- add a new section handler for these streams - check how this is done for e.g. MPEG4 sections
Once you have a new SCTE35 message extracted, you will need to forward it to the user (here the m2ts demux filter) through a new event type passing the parsed info, as done for TEMI.
We can then map this info to a packet property
Not sure we need to parse the entire set of SCTE35 descriptors, maybe a subset will do.
It would be nice to have one or two public reference TS with SCTE35 descriptors that we could include in the testsuite, would you have any ?
I found this in a FFMPEG question but I don't know if is legal https://www.mediafire.com/folder/zv20csqeo1ixt/
Hello @jeanlf @rbouqueau Thank you very much for your help! I am successfully reading the SCTRE-35 data but I have some problems/questions.
- I have created the event in the switch of
dmx_m2ts.c
very similar to TEMI but i am not sure if i have to save the data in the same placegf_list_add(en->props, data);
or how to map the info in some packet like you said in the previous comment - how can I receive the data in the dasher filter? it's required a new config in that filter? and finally ... how can I put the labels in manifests?
once again thank you for your help
I have created the event in the switch of dmx_m2ts.c very similar to TEMI but i am not sure if i have to save the data in the same place gf_list_add(en->props, data);or how to map the info in some packet like you said in the previous comment
I think that's a good approach yes. You may want to extend the GF_TEMIInfo structure to differentiate between TEMI and SCTE35 messages and change packet prop name in m2tsdmx_merge_temi.
how can I receive the data in the dasher filter? it's required a new config in that filter?
Nothing specific to do, the data will be passed along as packet properties, so all you need to do is check for the desired properties when processing a packet in the dasher
how can I put the labels in manifests?
What I would do (at least initially) is format the EXT-X-DATERANGE tag in the dasher, and add that info to the segment state, then serialize it after or before the segment crypt info
@JuanMorenoS Is there any progress or questions here?
@JuanMorenoS Is there any progress or questions here?