![]() |
TSDuck
v3.35-3218
MPEG Transport Stream Toolkit
|
Applications or TSP plugins can be developed on their own. But it is also possible to develop fully integrated extensions to TSDuck.
An extension not only adds new plugins and commands, it can also augment the features of standard TSDuck commands and plugins. An extension can also be packaged as a binary installer which can be deployed on top of an existing installation of TSDuck.
The possible features of a TSDuck extensions are:
tstables
and plugin tables
.tsp
.A complete example of a TSDuck extension is provided in the TSDuck source tree. This example also provides scripts to build standard installers (.exe
on Windows, .rpm
and .deb
on Linux). The generated packages install the extension on top of a matching version of TSDuck.
A TSDuck extension typically contains the following types of files:
tsp
plugins. They are dynamic libraries named tsplugin_XXX.so
, .dylib
or .dll
. The plugins are loaded by tsp
when invoked by their names XXX
.tslibext_XXX.so
, .dylib
or .dll
. All shareable libraries named tslibext_XXX
in the same directory as the TSDuck binaries or in the path TSPLUGINS_PATH
are automatically loaded when any TSDuck command is invoked (in fact any time the TSDuck library tsduck.dll
or libtsduck.so
or .dylib
is used). Such libraries typically install hooks into the core of TSDuck to handle third-party signalization.tslibext_XXX.xml
is recommended. These XML files must be registered by the extension dynamic library (details below).tslibext_XXX.names
is recommended. These files must be registered by the extension dynamic library (details below).All shareable libraries named tslibext_XXX.so
, .dylib
or .dll
are automatically loaded by any TSDuck command or plugin. The initialization of the library is responsible for registering various hooks which implement the additional features.
This is an optional but recommended step. One C++ module inside the tslibext_XXX
library shall invoke macro TS_REGISTER_EXTENSION as illustrated below:
Using this declaration, the extension is identified and listed using the command tsversion --extensions
.
Without the declaration, the extension is loaded and functional but it is not identified.
To analyze input XML files containing tables, TSDuck uses an XML model to validate the syntax of the input XML file. There is a predefined large XML file which describes all supported tables and descriptors.
An extension may provide additional smaller XML files which describe the new tables or descriptors. See the sample extension for more details. The XML files shall be installed in the same directory as the rest of the extension (and TSDuck in general).
For each additional XML file, there must be one C++ module inside the tslibext_XXX
library which invokes the macro TS_REGISTER_XML_FILE as illustrated below:
The usage rules and conventions are identical to the XML file above. The declaration macro for each names file is TS_REGISTER_NAMES_FILE as illustrated below:
Here is an example, from the sample "foo" extension, which defines additional names for a table, a descriptor and a range of CA_system_id.
If your environment defines a third-party table which is unsupported or unknown in TSDuck, you can implement it in your extension library.
First, define the C++ class implementing the table:
In the implementation of the table, register hooks for the various features you support. In this example, we register a C++ class for FooTable
:
The last argument to TS_REGISTER_TABLE is a static method of the class which displays the content of a section of this table type.
The XML model for the table is included in the XML file:
for the following binary layout:
Similarly, it is possible to implement a third-party descriptor as follow:
In the implementation of the descriptor, we register hooks for the various features. Since this is a non-DVB descriptor with descriptor tag 0xE8
, greater than 0x80
, we must set the private data specifier to zero in the ts::EDID ("extended descriptor id").
The last argument to TS_REGISTER_DESCRIPTOR is a static method of the class which displays the content of a descriptor.
The XML model for the descriptor is included in the XML file:
for the following binary layout:
The command tstables
(and its plugin counterpart tables
) can process vast amounts of tables. To extract specific tables or sections, the command provides filtering options such as --pid
, --tid
or --tid-ext
.
For specific sections, it is possible to define additional filtering options to the tstables
command.
The extension library shall provide a C++ class implementing ts::TablesLoggerFilterInterface. The sample "foo" extension provide an option --foo-id
which selects instances of FooTable
containing specific values for some "foo_id" field.
See the documentation of ts::TablesLoggerFilterInterface for more details.
In the implementation of the class, we register it as a section filter for tstables
:
If you work with a specific Conditional Access System, you probably manipulate confidential information that cannot be published in an open-source tool such as TSDuck. The solution is to develop a private closed-source extension.
In the extension library, you may register functions to display the structure of the ECM's, EMM's or private part of the CA_descriptor. The registration is based on a range of CA_system_id (here the constants CASID_FOO_MIN
and CASID_FOO_MAX
).
See the documentation for ts::DisplaySectionFunction, ts::LogSectionFunction and ts::DisplayCADescriptorFunction.
To register the display handlers in TSDuck:
See the sample "foo" extension in the TSDuck source tree.
Scripts are provided to build .exe
installers on Windows, .rpm
and .deb
packages on Linux.