Announce: RIST plugin for TSDuck
Hello,
For those who use TSDuck, I have pushed an initial version of a very simple RIST plugin.
If you haven't yet used TSDuck, this is a general-purpose toolbox for Digital TV engineers using MPEG transport streams. Its basic version comes with 13 input plugins, 11 output plugins and 72 packet processing plugins. Third-party or private proprietary plugins and extensions also exist.
The new rist
plugin is used as input and output plugin. The current version is simple, several sender/receiver URL's, encryption but no authentication for now.
The plugin documentation has been added in the TSDuck user's guide.
The rist
plugin can be compiled on Linux, macOS and Windows. However, it is not compiled by default on Linux because librist
is not available in any Linux distro. Building TSDuck binary packages with RIST support would create a dependency on non-existing librist
packages.
To build TSDuck yourself with RIST support, first install librist
. Either rebuild it and install it yourself or use one of the pre-built Linux packages from project rist-installer, a sister-project of TSDuck. Once librist
is installed, just use make RIST=1
to build TSDuck with RIST support. See more details here.
On Windows, the situation is simpler. There is no central repository and all tools and libraries must be downloaded from their original location. Moreover, a library which is compiled with a recent version of Windows can be used on all versions (this is not the case on Linux where each version of a distro has a specific repository of packages). The project rist-installer also provides binaries for Windows. These binaries are downloaded before building TSDuck, just like any other dependency. As a consequence, Windows is currently the only version of TSDuck with pre-built RIST support. The nightly builds will contain a RIST-enabled TSDuck by tomorrow (use version 2.28-2534 or higher).
On macOS, librist
has been recently added to Homebrew and TSDuck is now built is RIST support on macOS.
If anyone is interested in testing this, please do. Any feedback is welcome, especially since I am not a RIST expert (I didn't even know that acronym a few weeks ago, until a TSDuck user suggested to support RIST as input/output plugin).
I may have a few questions. I will post them in this thread. The first one concerns the granularity of transported data. Is RIST stream-oriented or message-oriented? If a block of N bytes is sent using rist_sender_data_write()
, is it guaranteed that the same N bytes are grouped in the same data block as read by rist_receiver_data_read2()
? In the case of MPEG transport streams, the sender always sends an integral number of TS packets. I would like to know if the received will get complete TS packets in each data blocks or if some sort of buffering / reassembly is required. In practice, my tests demonstrate that this is the case but is it guaranteed or just an effect of pushing chunks of data in the stream (as it is often the case with TCP, until it breaks).
If you are interested in the project rist-installer, we can discuss this too.