Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Support to SCTE - 35 #2158

Closed
JuanMorenoS opened this issue Mar 30, 2022 · 11 comments
Closed

Add Support to SCTE - 35 #2158

JuanMorenoS opened this issue Mar 30, 2022 · 11 comments

Comments

@JuanMorenoS
Copy link

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!

@rbouqueau
Copy link
Member

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?

@JuanMorenoS
Copy link
Author

Exactly that one! also I start to code that!

@JuanMorenoS
Copy link
Author

JuanMorenoS commented Mar 30, 2022

But i have a lot of problems/questions regarding the arch of the project

@jeanlf
Copy link
Member

jeanlf commented Mar 31, 2022

The first step is to demux the messages. You'll need to modify a bit the M2TS demuxer code :

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 ?

@JuanMorenoS
Copy link
Author

I found this in a FFMPEG question but I don't know if is legal https://www.mediafire.com/folder/zv20csqeo1ixt/

@JuanMorenoS
Copy link
Author

Hello @jeanlf @rbouqueau
Thank you very much for your help! I am successfully reading the SCTRE-35 data but I have some problems/questions.

  1. 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
  2. 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

@jeanlf
Copy link
Member

jeanlf commented Apr 4, 2022

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

@rbouqueau
Copy link
Member

@JuanMorenoS Is there any progress or questions here?

1 similar comment
@rbouqueau
Copy link
Member

@JuanMorenoS Is there any progress or questions here?

@rbouqueau
Copy link
Member

For those reading: WiP in #2748

@rbouqueau
Copy link
Member

#2748 merged. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants