SATPI icon indicating copy to clipboard operation
SATPI copied to clipboard

Request: Transformation mappings with FE support

Open lars18th opened this issue 3 years ago • 2 comments

Hi @Barracuda09 ,

At time I'm using the SATPI server to drive some "virtual" sources. These sources are broadcasts from the air using and external capture tool. So using the ChildPipe frontend I'm injecting the full transport stream from a PIPE, and tunning using fake satellite frequencies. It's easy and robust, so thank you for supporting this functionality.

However, now I want to expand this to use TWO virtual inputs. The idea is quite simple: As I've two external tuners, I want to drive two different ChildPipe frontends sharing the same frequencies but with different parameters. One example to illustrate it:

#EXTINF:-1 satip-freq="10714", Translation-1
rtsp://%1/?msys=childpipe&exec="inject-tool%20source1"&pcrtimer=1

That's my current mapping.m3u. In this case when you request the freq 10714 then the child pipe executes inject-tool source1 and reads from the PIPE. So, I can configure a second ChildPipe frontend and configure the same translation. But in this case the inject-tool requires to be reentrant, in the sense that it can handle more than one call at the same time. But this is false in my environment. However, if for example this tool can receive an additional parameter then it will possible to receive it and execute an alternative path based on this parameter. As example:

#EXTINF:-1 satip-freq="10714", Translation-1
rtsp://%1/?msys=childpipe&exec="inject-tool%20source1"&pcrtimer=1&addfe-param="-%d"

In this case, the child call will be inject-tool source1-0 or inject-tool source1-1, based on the fe 0 or 1 in use. Other options could be inject-tool source1 --frontend 1 if the mapping was addfe-param=" --frontend %d".

You think this has sense? It will be difficult to implement it? You have another different idea to achieve the same? Remember: my objective is to drive TWO different external "tuners" using the same FREQ mappings. Then I'll have from the point of view of the SAT>IP client a DUAL TUNER using the ChildPipe inputs.

Regards.

lars18th avatar Jun 29 '21 16:06 lars18th

Hi @lars18th

I am not sure what you mean (It seems very specific).

  • Why not make two satip-freq=
  • But were is the addfe-param= coming from qua input from client?
  • Is this the Tuner (ChildPIPE) number?

Kind Regards

Barracuda09 avatar Jul 02 '21 08:07 Barracuda09

Hi @Barracuda09 ,

Instead of a direct response to your questions, let me to explain first the use:

  SAT>IP client 1  -----
                       |                                    |--- ChildPipe ---> "external tuner A"  <--/ Freq=999.9
  SAT>IP client 2  ----+----> SATPI (mapping freq=999.9) ---+
                       |                                    |--- ChildPipe ---> "external tuner B"  <--/ Freq=999.9
  SAT>IP client 3  -----

So, take note that:

  • I can't use diffent satip-freq= as I want to serve to multiple clients. And the same frequency represents the same target freq in the external tuner. So it's not tuner A or tuner B, because both have the same inputs.
  • The NEW addfe-param is my suggestion to add to the syntax of the mappings.m3u file. It works similar to the pcrtimer parameter in the sense that it modifies the childpipe frontend. In this case it represents "a text to add to the command of the child pipe".
  • And yes, the %d is the Tuner number. So when the mapping contains something like rtsp://%1/?msys=childpipe&exec="inject-tool%20source1"&pcrtimer=1&addfe-param=" --frontend %d", then you only need to execute in a shell the result of "inject-tool source1" + printf(" --frontend %d",__tuner_number__);

Please, note that this is only a suggestion. My problem is how to call to the childpipe binary/script multiple times from different "Tuner numbers". I ask if you can provide without much changes a method to pass as a parameter the tuner number. This is to grant that SATPI only executes the child process one time with the same parameters.

I hope you have now a more clear view of the use case. Regards.

lars18th avatar Jul 02 '21 10:07 lars18th