Suggestion: Mappings with scripts

[lars18th]

Hi @Barracuda09 ,

Regarding the current MAPPING functionality (Translation) I have one suggestion:

• Add support for calling external scripts when events occur.

Look for current example of mapping.m3u:

#EXTINF:-1 satip-freq="11494", Translation to: Stream 1 - Multicast UDP input
udp://@224.0.0.1:12345

And see now this suggestion:

#EXTINF:-1 satip-freq="11494" start-script="/on.sh" stop-script="/off.sh" change-script="/pids.sh" token-script="12345", Translation to: Stream 1 - Multicast UDP input
udp://@224.0.0.1:12345

And the you call to:

• start-script: when the frequency is tunned, so as the scoket is opened.
• stop-script: when the frequency is down, so as the socket is closed.
• change-script: when something changes in the tuner, like when the "pids" list is modified.

Futhermore, these scripts receive three parameters:

• %1: that's the token-script value, used for identifying the channel (and 0 if it's not set).
• %2: the full list of the SAT>IP request "received", for example "/?freq=658&sr=6900&msys=dvbc&mtype=256qam&fec=35".
• %3: the current pid list used, like "pids=all", "pids=0,10,20"; but not with "addpids" or "delpids".

What you think?

[lars18th]

Hi,

The idea behind this suggestion is to control another service that generates multicast streams. With this functionality it would be possible to control any tool that can stream TS services and send them to multicast/unicast addresses.

I hope you'll like to implement it! :wink:

[lars18th]

Hi,

I put here one comment as a reference: If you need to execute some command at start or when closing then you can use the scripting mode described in #102. The only missing event is the pid change, however, only in some special cases this will be required. Perhaps in the future someone can provide a broker mode (ZeroMQ or MQTT) than can broadcast the status/events.

Regards.

[lars18th]

Hi @Barracuda09 ,

I want to drive a server that can filter the pid list using the childpipe. So, could you please comment about a simple method to share this information with the subprocess? Perhaps my suggestion about calling a script and passing a token every time the pid list changes is not good for you. Or perhaps you don't think this option will be necessary. But from my point-of-view, this is the only remaining functionality of the childpipe input to handle any type of source. For example, to consume from any type of tuners: external hardware, HDHomeRuns, virtual tuners, streamers, SAT>IP servers, etc.

This project it's very interesting and robust. And I want to use it to proxy other type of tuners. So, for this objective a pid handle it's required (because the option to send the full transport stream is not feasible every time).

Please could you comment? Thank you!

[Barracuda09]

Hi @lars18th

You mean that the xxxpids=d,dd,ddd in the request, should be passed to the childpipe request, like a wget request?

[lars18th]

Hi @Barracuda09 ,

You mean that the xxxpids=d,dd,ddd in the request, should be passed to the childpipe request, like a wget request?

Thank you for your response!

More or less the answer is "no", because this:

• What I request is to make a callback/hook to a user script every time the pid list changes. The case when the initial request includes a pid list could be resolved calling to this script after the childpipe is launched. If we consider that the initial pid-list is "none" (pids=none), then if the initial SETUP/PLAY command includes a pids=... then it will be the same as a change from "none" to this list. As you can imagine, the list is fully shared. So any addpids= and delpids=, are changing the pid list and only after processing all commands the current pid-list is sended.

However, my comment is about the best, or most simple, solution to share this pid-list with the subprocess. Perhaps a call to a script in every pid change has a large overhead. In this case, a limit of calls at every X milliseconds could be necessary. Or a different approach could be used: open the childpipe with a PIPE input and send to the pipe a line with the pid-list. As an example:

pids=0
pids=0,11,16,18,100,101
pids=0,200,201
pids=none
pids=0

So then the childpipe could process it (or not). For sure this will be optional. In this case the call could be like this example in the mapping.m3u:

#EXTINF:-1 satip-freq="204", Translation to: ChildPIPE (with piped pids) exec="wget -qO- http://192.168.0.112:8875/?freq=418%26sr=6900%26msys=dvbc%26mtype=256qam%26fec=35%26pids=0,1,16,17,18,2600,2601,2611"
rtsp://@#1/?msys=childpipe&pipepids=true&exec="wget%20-qO-%20http:%2F%2F192.168.0.112:8875%2F%3Ffreq=418%%26sr=6900%%26msys=dvbc%%26mtype=256qam%%26fec=35%%26pids=0,1,16,17,18,2600,2601,2611"

Here the change is the &pipepids=true in the childpipe call. In this case the childpipe subprocess will be opened with the STDIN connected to a function that prints the pids-list in the correct format after any change on the internal list.

What you think?