 |
TSDuck v3.38-3696
MPEG Transport Stream Toolkit
|
|
TSDuck v3.38-3696
MPEG Transport Stream Toolkit
|
TSDuck can be built on Windows, Linux, macOS and BSD systems.
Support for Dektec devices, DVB tuners and HiDes modulators is implemented only on Windows and Linux. MacOS and BSD systems can only support files and networking for TS input and output.
Some protocols such as SRT and RIST require external libraries which may not be available on all platforms or all versions of a specific distro.
TSDuck has been tested on the following operating systems on at least one CPU architecture.
| OS | Variants |
|---|---|
| macOS | |
| Windows | |
| Linux | Ubuntu, Debian, Raspbian, Mint, Fedora, Red Hat, CentOS, Rocky, Alma, openSUSE, Arch, Alpine, Gentoo |
| BSD | FreeBSD, OpenBSD, NetBSD, DragonFlyBSD |
TSDuck has been tested on the following CPU architectures on at least one operating system.
| Architecture | Bits | Endian |
|---|---|---|
| Intel x86 | 32 | Little |
| Intel x86-64 | 64 | Little |
| Armv7 | 32 | Little |
| Armv8 | 64 | Little |
| MIPS | 32, 64 | Little |
| RISC-V | 64 | Little |
| PowerPC | 64 | Big |
| IBM s390x | 64 | Big |
Note: Some tests were done by contributors and were not verified. Some tests were performed using qemu, on an emulated platform, not a physical CPU. This is the case for RISC-V, PowerPC, IBM s390x.
TSDuck has been tested with the following compilers on at least one operating system.
| Compiler | OS | Minimum version |
|---|---|---|
| GCC | Linux, BSD | 11.0 |
| Clang | Linux, macOS | 5.0 |
| MSVC | Windows | Visual Studio 2017 15.8 |
The required minimum version of each compiler depends on a correct implementation of C++17. Previous versions of each compiler have no or buggy C++17 support.
Operations in this section must be run once, before building TSDuck for the first time one a given system.
Execute the shell-script scripts/install-prerequisites.sh. It downloads and installs the requested packages which are necessary to build TSDuck. The list of packages and how to install them depend on the operating system distribution and version.
If you intend to use exclusion options in the make command line (for instance NOSRT=1 NORIST=1), specify them to scripts/install-prerequisites.sh too. This will prevent the installation of unused libraries. Additional supported exclusion options are NOJAVA=1 NODOXYGEN=1.
Currently, the script supports all Unix operating systems which were listed above.
Since all packages are pulled from the standard repositories of each distro, there is generally no need to re-run this script later. The packages will be updated as part of the system system updates. Note, however, that a new version of TSDuck may require additional dependencies. In case of build error, it can be wise to run scripts/install-prerequisites.sh again and retry.
TSDuck now requires a C++17 compliant compiler. GCC is supposed to support C++17 from version 8 onwards. Clang needs version 5 at least.
However, building TSDuck with GCC versions 8 to 10 fails because of bugs in the compiler. C++17 support in GCC really works starting with version 11.
All recent Linux distros use GCC 11, 12 or 13. Some older distros which come with older GCC versions may propose alternative GCC packages with more recent versions.
If your distro is too old and doesn't provide any GCC 11 or clang 5 package, then you cannot build TSDuck version 3.36 and higher. On such systems, the highest TSDuck version which can be built is 3.35. This is the cost of obsolescence...
Another alternative is to use LLVM/clang. Most distros with old versions of GCC provide decently recent versions of clang. To force a build with LLVM/clang instead of GCC, defined the make variable LLVM:
However, when the installed GCC is really old (typically before GCC 8), using clang may not work either because clang uses the GCC C/C++ standard libraries and their header files. If the GCC issue is a compilation issue on GCC 8 to 10, using clang may work. With older versions of GCC, using clang probably does not work because the corresponding standard library does not contain the C++17 features.
Starting with RedHat Entreprise Linux 9, all GCC versions correctly support C++17.
However, RedHat Entreprise Linux 8.8 comes with GCC 8.5.0. You can install and use GCC 11 using the following commands:
The first command installs the GCC 11 packages. The second command defines the required environment variables in the current process. The last one builds TSDuck. Note that the GCC 11 packages are available in the AppStream repository. Make sure to have activated it first.
Older versions of other distros such as Ubuntu, Debian and others have equivalent alternative packages for GCC 11, with different names, when they come with an older version of GCC.
If there is no enable script (as in the example above) to setup the environment, you need to define the following variables, either as environment variables or on the make command line. The provided values are examples only and may be different in specific environments.
Since make uses the environment for the initial values of its variables, it is also possibe to define them as environment variables in some initialization script instead of using such a complex make command..
As of this writing, the most recent version of NetBSD is 9.3, which comes with GCC 7.5. More recent GCC packages are available. To install GCC 13:
The compilation environment is installed in /usr/pkg/gcc13. Using GCC 13 is simply enabled by adding /usr/pkg/gcc13/bin at the beginning of the PATH:
As of this writing, the most recent version of DragonFlyBSD is 6.4.0, which comes with GCC 8.3. Even though DragonFlyBSD is supposed to be based on FreeBSD, its GCC version is way behind FreeBSD version 14.0 which comes with GCC 12.2.
More recent GCC packages are available for DragonFlyBSD. To install GCC 13:
However, because all *BSD systems are carefully incompatible between each other, using the alternative compiler is very different from NetBSD. Building TSDuck:
Since make uses the environment for the initial values of its variables, it is also possibe to define them as environment variables in some initialization script instead of using such a complex make command..
Dektec DTAPI : The command make at the top level will automatically download the LinuxSDK from the Dektec site. There is no manual setup for DTAPI on Linux. Note that the Dektec DTAPI is available only for Linux distros on Intel CPU's with the GNU libc. Non-Intel systems (for instance ARM-based devices such as Raspberry Pi) cannot use Dektec devices. Similarly, Intel-based distros using a non-standard libc (for instance Alpine Linux which uses musl libc) cannot use Dektec devices either.
Vatek API : On Linux, the command make at the top level will automatically download the Linux version of the Vatek API from the GitHub. There is currectly no Linux package for the Vatek API in the standard distros. On Windows and macOS, binary packages are available and are installed by the install-prerequisites scripts. Using Vatek devices on BSD systems is currently not supported but should work if necessary (accessing Vatek devices is performed through libusb and not a specific kernel driver).
On FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, the standard BSD make command uses an old syntax. The makefiles in the TSDuck project use a GNU Make syntax and are not compatible with the BSD make command. As part of prerequisites for BSD systems, GNU Make is installed under the name gmake. In all build commands in this page, when make is mentioned, use gmake on all BSD systems.
Execute the command make at top level.
The TSDuck binaries, executables and shared objects (.so or .dylib), are built in directory bin/release-<arch>-<hostname> by default. Consequently, the same work area can be simultaneously used by several systems. Each system builds in its own area. You can also override the build directory using make BINDIR=....
Note that TSDuck contains thousands of source files and building it can take time. However, since most machines have multiple CPU's, all makefiles are designed for parallel builds. On a quad-core machine with hyperthreading (8 logical cores), for instance, the command make -j10 is recommended (10 parallel compilations), reducing the total build time to a few minutes.
To cleanup the repository tree and return to a pristine source state, execute make clean at the top level.
In specific configurations, you may want to disable some external libraries such as libcurl or pcsc-lite. Of course, the corresponding features in TSDuck will be disabled but the impact is limited. For instance, disabling libcurl will disable the input plugins http and hls.
The following make variables can be defined:
NOTEST : Do not build unitary tests.NODEKTEC : No Dektec device support, remove dependency to DTAPI.NOHIDES : No HiDes device support.NOVATEK : No Vatek device support (modulators based on Vatek chips).NOCURL : No HTTP support, remove dependency to libcurl.NOPCSC : No smartcard support, remove dependency to pcsc-lite.NOEDITLINE : No interactive line editing, remove dependency to libedit.NOSRT : No SRT support (Secure Reliable Transport), remove dependency to libsrt.NORIST : No RIST support (Reliable Internet Stream Transport), remove dependency to librist.NOHWACCEL : Disable hardware acceleration such as crypto instructions.ASSERTIONS : Keep assertions in production mode (slower code).The following command, for instance, builds TSDuck without dependency to pcsc-lite, libcurl and Dektec DTAPI:
The following additional make variables can be defined to enable specific debug capabilities:
DEBUG : Compile with debug information and no optimization.GPROF : Compile with code profiling using gprof.GCOV : Compile with code coverage using gcov.ASAN : Compile with code sanitizing using AddressSanitizer with default optimization.UBSAN : Compile with code sanitizing using UndefinedBehaviorSanitizer with default optimization.Because of the number of include directories and warning options, the compilation commands are very long, typically more than 4000 characters, 30 to 50 lines on a terminal window. If the make commands displays all commands, the output is messy. It is difficult to identify the progression of the build. Error messages are not clearly identified.
Therefore, the make command only displays a synthetic line for each command such as:
In some cases, if can be useful to display the full compilation commands. To do this, define the variable VERBOSE as follow:
For convenience and compatibility with some tradition, V can be used instead of VERBOSE.
Execute the command make installer at top level to build all packages.
Depending on the platform, the packages can be .deb or .rpm files. There is currently no support to build an installation package on other Linux distros and BSD systems.
There is no need to build the TSDuck binaries before building the installers. Building the binaries, when necessary, is part of the installer build.
All installation packages are dropped into the subdirectory pkg/installers. The packages are not deleted by the cleanup procedures. They are not pushed into the git repository either.
Special note on macOS : There is no binary package for TSDuck on macOS. On this platform, TSDuck is installed using Homebrew, a package manager for open-source projects on macOS. See here for more details.
Packagers of Linux distros may want to create TSDuck packages. The build methods are not different. This section contains a few hints to help the packaging.
By default, TSDuck is built with capabilities to check the availability of new versions on GitHub. The tsversion command can also download and upgrade TSDuck from the binaries on GitHub. Packagers of Linux distros may want to disable this since they prefer to avoid mixing their TSDuck packages with the generic TSDuck packages on GitHub. To disable this feature, build TSDuck with make NOGITHUB=1.
The way to build a package depends on the package management system. Usually, the build procedure includes an installation on a temporary fake system root. To build TSDuck and install it on /temporary/fake/root, use the following command:
It is recommended to create two distinct packages: one for the TSDuck tools and plugins and one for the development environment. The development package shall require the pre-installation of the tools package.
If you need to separately build TSDuck for each package, use targets install-tools and install-devel instead of install which installs everything:
On systems where you have no administration privilege and consequently no right to use the standard installers, you may want to manually install TSDuck is some arbitrary directory.
You have to rebuild TSDuck from the source repository and install it using a command like this one:
The TSDuck commands are located in the bin subdirectory and can be executed from here without any additional setup. It is probably a good idea to add this bin directory in your PATH environment variable.
Applications may use the pkgconfig utility to reference the TSDuck library. A file named tsduck.pc is installed in the appropriate directory.
However, pkgconfig has its own limitations, specifically regarding the configured compilation options.
TSDuck is a C++ library which requires a minimum revision of the language. Currently, the minimum revision is C++17. All more recent revisions are supported. By default, most C++ compilers are based on older revisions. Therefore, compiling an application using TSDuck with the default options fails. At least, -std=c++17 is required. To avoid compilation problems with most applications, -std=c++17 is enforced in tsduck.pc.
However, some applications may need to explicitly specify a more recent revision, such as -std=c++14 or -std=c++20, which conflicts with -std=c++17 in tsduck.pc.
For that use case, you may install TSDuck without reference to the C++ revision using the following command:
The counterpart is that the applications must specify a -std option and the revision must be C++17 or more recent.
A generic solution would be that each library and the application all provide a minimum revision of the C++ language and pkgconfig would provide a synthetic -std option which fulfills all requirements. However, this feature does not exist in pkgconfig, hence this trick.
It is sometimes useful to run a TSDuck binary, tsp or any other, directly from the build directory, right after compilation. This can be required for testing or debugging.
Because the binary directory name contains the host name, it is possible to build TSDuck using the same shared source tree from various systems or virtual machines. All builds will coexist using distinct names under the bin subdirectory.
For bash users who wish to include the binary directory in the PATH, simply "source" the script scripts/setenv.sh. Example:
This script can also be used with option --display to display the actual path of the binary directory. The output can be used in other scripts (including from any other shell than bash). Example:
Use scripts/setenv.sh --help for other options.
Operations in this section must be run once, before building TSDuck for the first time one a given system. It should also be run to get up-to-date versions of the build tools and libraries which are used by TSDuck.
First, install Visual Studio Community Edition. This is the free version of Visual Studio. It can be downloaded here. If you already have Visual Studio Enterprise Edition (the commercial version), it is fine, no need to install the Community Edition.
Then, execute the PowerShell script scripts\install-prerequisites.ps1. It downloads and installs the requested packages which are necessary to build TSDuck on Windows.
If you prefer to collect the various installers yourself, follow the links to NSIS downloads, Git downloads, SRT downloads, RIST downloads, Dektec downloads, Vatek downloads, Java downloads, Python downloads, Doxygen downloads and Graphviz downloads.
TSDuck now requires a C++17 compliant compiler. C++17 support started with Visual Studio 2017 15.8. We recommend to use Visual Studio 2022.
Execute the PowerShell script scripts\build.ps1. The TSDuck binaries, executables and DLL's, are built in directories named bin\<target>-<platform>, for instance bin\Release-x64 or bin\Debug-Win32.
To cleanup the repository tree and return to a pristine source state, execute the PowerShell script scripts\cleanup.ps1.
Execute the PowerShell script pkg\nsis\build-installer.ps1. By default, only the 64-bit installer is built. To build the two installers, for 32-bit and 64-bit systems, run the build script from a PowerShell window and add the option -Win32.
There is no need to build the TSDuck binaries before building the installers. Building the binaries, is part of the installer build.
All installation packages are dropped into the subdirectory pkg/installers. The packages are not deleted by the cleanup procedures. They are not pushed into the git repository either.
On systems where you have no administration privilege and consequently no right to use the standard installers, you may want to manually install TSDuck is some arbitrary directory.
On Windows systems, a so-called portable package is built with the installers. This is a zip archive file which can be expanded anywhere.
It is sometimes useful to run a TSDuck binary, tsp or any other, directly from the build directory, right after compilation. This can be required for testing or debugging.
The commands can be run using their complete path without additional setup. For instance, to run the released 64-bit version of tsp, use:
For other combinations (release vs. debug and 32 vs. 64 bits), the paths from the repository root are:
The following table summarizes the packages which are built and dropped into the pkg/installers directory, through a few examples, assuming that the current version of TSDuck is 3.12-745.
| File name | Description |
|---|---|
| tsduck_3.12-745_amd64.deb | Binary package for 64-bit Ubuntu |
| tsduck_3.12-745_armhf.deb | Binary package for 32-bit Raspbian (Raspberry Pi) |
| tsduck-3.12-745.el7.x86_64.rpm | Binary package for 64-bit Red Hat 7.x and clones |
| tsduck-3.12-745.el7.src.rpm | Source package for Red Hat 7.x and clones |
| tsduck-3.12-745.fc25.x86_64.rpm | Binary package for 64-bit Fedora 25 |
| tsduck-3.12-745.fc25.src.rpm | Source package for Fedora 25 |
| tsduck-dev_3.12-745_amd64.deb | Development package for 64-bit Ubuntu |
| tsduck-dev_3.12-745_armhf.deb | Development package for 32-bit Raspbian (Raspberry Pi) |
| tsduck-devel-3.12-745.el7.x86_64.rpm | Development package for 64-bit Red Hat 7.x and clones |
| tsduck-devel-3.12-745.fc25.x86_64.rpm | Development package for 64-bit Fedora 25 |
| TSDuck-Win32-3.12-745.exe | Binary installer for 32-bit Windows |
| TSDuck-Win64-3.12-745.exe | Binary installer for 64-bit Windows |
| TSDuck-Win32-3.12-745-Portable.zip | Portable package for 32-bit Windows |
| TSDuck-Win64-3.12-745-Portable.zip | Portable package for 64-bit Windows |
On Linux systems, there are two different packages. The package tsduck contains the tools and plugins. This is the only required package if you just need to use TSDuck. The package named tsduck-devel (Red Hat family) or tsduck-dev (Debian family) contains the development environment. It is useful only for third-party applications which use the TSDuck library.
On Windows systems, there is only one binary installer which contains the tools, plugins, documentation and development environment. The user can select which components shall be installed. The development environment is unselected by default.
On macOS systems, the Homebrew package tsduck installs all components.
1.9.8