[Q] is there a way to output to generic virtual tuner?

[homer314]

Hi, first, thanks for give us this incredible project. I would like to manipulate some media and encapsulate in a TS using tsduck. Then i would like to delivery these TS using, for example sat>ip protocol. Most sat>ip server only accept tuners as input, so my question is: is there any workaround to feed a sat>ip server or any other application that expect a tuner, using tsduck (or a more complex pipe, of course)?

Regards Flavio

[lars18th]

Hi Flavio (@homer314),

I'm using and working a lot with the SAT>IP protocol. So give me the option to comment about your request:

• In general your request is not possible. Why? Because the TSDuck can "read", "process" and "output" a Transport Stream. And any SAT>IP tuner is a device that gets the TS from the wire (modulated signal). Then for a technical environment what you need is a DVB-T/S/C modulator that will be feed from TSDuck and a SAT>IP server that receives directly this signal.

That's the overall method to work with TSDuck & SAT>IP. However, you can do some "tricks" to overcome the modulator and the tuner and do all in software.

• Based on the idea that the output of the TSDuck is a simple bitstream, you can use it to feed some SAT>IP software server that can read the stream from sources different than a tuner. For example, you can use the SATPI tool (search it in github) that can read from UDP or PIPE. It uses a mapping M3U file that can map different sources (TS streams) to regular transponder frequencies. Then any SAT>IP client that connects to this server can receive the bitstream produced by TSDuck. Only one suggestion to reduce troubles: The output from TSDuck requires to be CBR and DVB conformant (in fact a regular MPTS). Then the SATPI will reads and filters the stream as it will comes from a real tuner.

The only limitation with this environment is that you need to start the TSDuck process externally and feed the stream continously (for example to one UDP multicast address). So if you need to work on-demand, then it will be more complex. Using the PIPE input of the SATPI server you can start the processing and read from the PIPE. However, this has some limits as you need to create a shell wrapper to control the subprocess of TSDuck and the PIPE.

For sure it will glorious if TSDuck will accepts the SAT>IP protocol as one output. However, this is complex and far from the KISS model. However, perhaps @lelegard will want at some point implement some "realtime filtering operation" to do an easy interconnection with a SAT>IP server. That's because the work done by this protocol with the tuner is read (done) and filter (pending). But in any case, it can be more "simple" to implement a "vtuner" output module. This will be more general and perhaps useful for TSDuck users. In this case, any SAT>IP software server could use this virtual tuner (I've done it in the past to interconnect two SAT>IP servers in a chained mode).

@lelegard , What you think about a "vtuner driver output plugin" for TSDuck? It's a crazy idea? Linux vtuner driver: https://github.com/Leatherface75/vtuner.linux-driver

[homer314]

Thank you very much for suggestions @lars18th. Onestly, i didn't start this thread to ask about adding sat>ip as output in tsduck, but i don't see too much distance between a detek/hides modulator support and a fake/software virtual tuner in terms of added value for tsduck project. It is what you suggest, and it is exactly what i was thinking about/looking before starging this thread :)

Regards

[lars18th]

Hi @homer314 ,

[...] i don't see too much distance between a detek/hides modulator support and a fake/software virtual tuner in terms of added value for tsduck project.

After more thinking about this, I feel that perhaps you're right and the vtuner support could be interesting. However, before requesting to @lelegard to implement this, I prefer to think if this has sense and the best solution to implement it (aka the more simple solution).

Perhaps a good aproximation could be this:

• Start implementing a vtuner server process in the userland level that could read the stream from a PIPE.
• Then be can execute something like this: tsp ... | vtuner-server. And then any DVB application can use this virtual tuner to read the stream outputing from the tsp process.
• This could be the first step, and it doesn't require to change anything inside TSDuck.

And after that...

• The next level could be then to introduce the two functionalities of a tuner: "channel tunning" and "pid filtering".
• For the last could be easy to implement it. However, for the first it will be necessary to define an interface to execute the tsp process on request. And do some mapping between frequencies<-->filters process.

Perhaps @lelegard could comment about his vision about this. Any idea? We're crazy requesting this?

[lelegard]

The normal behaviour of a tuner is getting tuning parameters (frequency and the rest) and selecting one TS from these parameters. So, this is selecting one source TS from many.

Using TSDuck, the only application which does this is tsswitch. Switching from one source to another can be triggered by very simple text messages such as "0", "1" in UDP messages. You must implement the mapping between tuning parameters and input index in some application (maybe a simple script) which sends the corresponding index to tsswitch.

[lelegard]

Alternatively, you may use the TSDuck "tuner emulator" (RTFM section 7.1.4). Use the standard dvb input plugin but specify an XML file as "tuner device". The mapping between tuning parameters and the input to select (TS file or output of a command) is automatically done in the tuner emulator. The drawback is that you cannot dynamically change the input. Maybe you can try to restart the input dvb plugin through a tsp control port.

[lars18th]

Hi @lelegard ,

Thank you for your comment! Personally I feel that is not necessary to include some vtuner or similar functionality in the output of the TSDuck, as this could be done with external tools. However, please let me to comment one key point:

The normal behaviour of a tuner is getting tuning parameters (frequency and the rest) and selecting one TS from these parameters. So, this is selecting one source TS from many.

That is not really true. The interface of a DTV tuner includes two main functionalities: "tunning" and "filtering". This is actually true in Linux drivers, BDA Windows drivers, SAT>IP protocol, HDHR protocol, etc. The current implementation of the "tsswitch" tool could be used for the tunning function. But for the filtering functionality we lack this... in the sense of a Remote Control of the filtering. And yes, I know that the regular processing of TSDuck is based on the full Transport Stream. So typically you use the tuner to get all pids. But this is not the only one use of a DTV tuner.

So, I suggest to consider to improve the filtering filter to add the remote management using UDP commands (or create a similar tool to "tsswitch" called "tsfilter" that does it). With this functionality added then it will possible to create a "vtunerd" process (or any other tool) that uses TSDuck to simulate a DTV Tuner.

You agree with that?

[lelegard]

So, I suggest to consider to improve the filtering filter to add the remote management using UDP commands

Use a -P filter in a tsp command with a control port. Then restart it with different parameters using tspcontrol (or a direct TCP connection to the control port).

[lars18th]

So, I suggest to consider to improve the filtering filter to add the remote management using UDP commands

Use a -P filter in a tsp command with a control port. Then restart it with different parameters using tspcontrol (or a direct TCP connection to the control port).

Great! Yes, I forget this option. 😉 Thank you @lelegard !

Another question: What you think about adding IGMP support fot the ip output plugin? The idea is quite simple: if no client is listening to the multicast address then the tsp process is stalled. And when one client joins the multicast group then the tsp process continues the execution. This will be a simple and a powerfull method to start/stop multiple tsp instances with different sources. And it can be used with an external tuner emulator. What you think about this?