 |
TSDuck Version 3.19-1374 (TSDuck - The MPEG Transport Stream Toolkit) | 
|
|
TSDuck Version 3.19-1374 (TSDuck - The MPEG Transport Stream Toolkit) |
|
TSDuck can be built on Windows, Linux and macOS.
Support for Dektec devices, DVB tuners and HiDes modulators is implemented only on Windows and Linux. macOS can only support files and IP for TS input and output.
dektec\Download-Install-Dtapi.ps1. It downloads and installs the Dektec Windows SDK from the Dektec site. Alternatively, you may download it here. TSDuck project files will detect DTAPI automatically. See the Visual Studio property file build\msvc\msvc-use-dtapi.props for details.make m32): make m32): libcurl3 has been replaced by libcurl4 and the installation commmand becomes: make m32) because there is no 32-bit cross-compiled package for pcsc on Ubuntu 64-bit.It has been noted that GCC 6 and 7 are broken and fail to compile TSDuck version 3.17 and higher. As of TSDuck version 3.17, the latest versions of the major Linux distros (Fedora, CentOS, Red Hat Entreprise, Ubuntu) have either older or newer versions of GCC. However, Raspbian 9.x and Debian 9.x (stretch) embed GCC 6.x. Similarly, Ubuntu 18.04 embeds GCC 7.x.
If you have such a broken GCC, it is recommended to install an older or newer version of GCC.
The following method has been successfully used to build TSDuck on Raspbian 9.9. The compiler is GCC 4.9, an older but valid version, which is available from the official repo.
On Debian 9.x (stretch), it has been reported from users that you need to add the following line in file /etc/apt/sources.list before installing GCC 4.9:
To install GCC 4.9:
Build TSDuck using the following command. The compiler and associated tools are redirected to their version 4.9.
If you encounter errors from the ar tool, complaining about an unknown U option, you may have an outdated binutils package (probably a version prior to 2.28). In that case, add the option ARFLAGS=rc to the make command above.
make at the top level will automatically download the LinuxSDK from the Dektec site. See dektec/Makefile for details.Execute the PowerShell script build\Build.ps1. The TSDuck binaries, executables and DLL's, are built in directories msvc\Release-Win32 and msvc\Release-x64 for 32-bit and 64-bit platforms respectively.
Execute the command make at top level. The TSDuck binaries, executables and shared objects (.so), are built in the src directory tree in subdirectories release-i386 and release-x86_64 for 32-bit and 64-bit platforms respectively.
To build a 32-bit version of TSDuck on a 64-bit system, execute the command make m32.
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 plugin http (the plugin will still be there but it will report an error when used).
The following make variables can be defined:
NOTEST : Do not build unitary tests.NODTAPI : No Dektec support, remove dependency to DTAPI.NOCURL : No HTTP support, remove dependency to libcurl.NOPCSC : No smartcard support, remove dependency to pcsc-lite.NOTELETEXT : No Teletext support, remove teletext handling code.The following command, for instance, builds TSDuck without dependency to pcsc-lite, libcurl and Dektec DTAPI:
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 installers. The packages are not deleted by the cleanup procedures. They are not pushed into the git repository either.
Execute the PowerShell script build\Build-Installer.ps1. Two installers are built, for 32-bit and 64-bit systems respectively.
Execute the command make rpm at top level to build a .rpm package for the same architecture as the build system. On 64-bit systems, execute the command make rpm32 to build a 32-bit package.
Execute the command make deb at top level to build a .deb package for the same architecture as the build system.
The following table summarizes the packages which are built and dropped into the installers directory, through a few examples, assuming that the current version of TSDuck is 3.12-745.
| File name | Description |
|---|---|
| TSDuck-3.12-745-src.zip | Source archive on Windows |
| tsduck-3.12-745.tgz | Source archive on Linux and macOS |
| 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.i386.rpm | Binary package for 32-bit Red Hat or CentOS 7.x |
| tsduck-3.12-745.el7.x86_64.rpm | Binary package for 64-bit Red Hat or CentOS 7.x |
| tsduck-3.12-745.el7.src.rpm | Source package for Red Hat or CentOS 7.x |
| tsduck-3.12-745.fc25.i386.rpm | Binary package for 32-bit Fedora 25 |
| 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.i386.rpm | Development package for 32-bit Red Hat or CentOS 7.x |
| tsduck-devel-3.12-745.el7.x86_64.rpm | Development package for 64-bit Red Hat or CentOS 7.x |
| tsduck-devel-3.12-745.fc25.i386.rpm | Development package for 32-bit Fedora 25 |
| 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 (or tsduck-dev on Ubuntu) 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 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 provided. This is a zip archive file which can be expanded anywhere.
On Unix systems (which include Linux and macOS), you have to rebuild TSDuck from the source repository and install it using a command like this one:
In all cases, Windows or Unix, 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.
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.
On Windows, the binaries and all plugins are built in a subdirectory named build\msvc\<target>-<platform>. The commands can be run using their complete path.
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:
On all Unix systems, the binaries, plugins and tests are built in subdirectories of their respective source directories. Specifically, the tools and plugins are not in the same directory.
To run a tool from its build directory, a few environment variables shall be defined (including $PATH). A shell-script named setenv.sh is automatically created in each build directory. This script defines the appropriate environment for running binaries which are in this build directory.
Depending on your target (release vs. debug, 32 bits vs. 64 bits, Intel vs. ARM), execute one of:
Note the usage of the source command to make sure that the environment variables are defined in the current shell.
Example:
On Windows, to cleanup a repository tree and return to a pristine source state, execute the following PowerShell script:
On Linux and macOS, the same cleanup task is achieved using the following command: