dvbmux multiplexing core is a fully-featured, real time MPEG-2 systems remultiplexer implemented in software, written with DVB broadcasting environment in mind. Running under control of a inux kernel, dvbmux may replace overpriced hardware solutions in digital broadcasting headends or TV studios.
The design priorities of this application were reliability and performance. On decent machines, dvbmux may process up to several Gbit/s of MPEG-2 Transport Streams.
Key features of dvbmux:
Typically, dvbmux is provided preinstalled together with a customized Realtime Linux operating system. Under normal circumstances, the user will not be required to install dvbmux.
dvbmux does not require any other files except the executable to start. The exact location of the executable makes no difference.
Configuration is loaded from/saved to "mux.config" file in the current working directory; in order to save the configuration the CWD must be writable (it must be possible to create temporary files in this directory).
The executable is meant to be run as root.
dvbmux can be started as easily, as typing ./mux. If a configuration file is found (by default, under "mux.config" in the current working directory), the binary will configure itself accordingly and start multiplexing. In case the configuration file does not exist, the core will start with an empty configuration (idling, without any inputs or outputs).
The multiplexer configuration is set and changed thorugh a command-line interface (CLI), that is available via telnet connection to TCP port 8001 of the local host. Use the standard Linux telnet client to access the CLI, eg. telnet localhost 8001. For a short introduction how to configure the multiplexer, please consult the attached TUTORIAL file.
The binary accepts a few start-up options, through which a few global parameters can be altered:
-s [port] Change the CLI port -a [ip] Bind the CLI to the specified interface address -c [name] Specify alternative name of configuration file -r [prio] Ask the OS for SCHED_FIFO (realtime) scheduling -b Relaxed timing regime -m Dummy mode - do not start I/O. -h Show version information and help
According to how the user configures the output MPEG-2 Transport Streams, dvbmux internally constructs and maintains an output schedule that keeps track of when output packets are to be sent. Depending on jitter requirements, the user may choose how precise this schedule will be kept.
By default, to wait for the next scheduled output event, dvbmux keeps running in a busy loop, constantly checking current system time versus next scheduled event time. This keeps the output jitter low, but is ineffective in terms of CPU usage. Besides, it lowers the maximal processing throughput of dvbmux on a specific hardware configuration.
Alternatively, the user may start dvbmux under a relaxed timing regime by passing the -b commandline option. In this case, dvbmux calls the OS (clock_nanosleep()) in order to wait for next scheduled events. Because of limited temporal resolution of the Linux process scheduling subsystem, this will inherently increase output jitter and sometimes can upset devices to which mux sends its output streams. In most cases however, the jitter is tolerable and thus it makes perfect sense to use the -b option in order to save CPU time, so that there is more processing power available for receiving inputs.
If dvbmux is run under control of a real-time Linux kernel (ie. one with the real-time patch applied), it is mostly advisable to pass the -r commandline option on startup. This will cause dvbmux to use real-time system calls to control the output schedule, achieving both low jitter and low CPU usage.
dvbmux is configured using a text mode command line interface, that is available through telnet protocol over TCP/IP. Please read the attached TUTORIAL file to learn how to configure dvbmux through this interface.
Sileman also offers a web-based GUI that connects to the CLI and enables the digital TV system administrator to configure dvbmux completely without logging into the text-mode CLI.
Dvbmux is a multi-threaded application. The most CPU intensive threads are the input and output thread. The former processes all incoming MPEG-2 Transport Streams and routes elementary streams into their proper buffers. The latter does the actual remultiplexing, which involves assembling UDP packets out of appropriate elementary stream buffers.
There are also three "best-effort" auxillary threads: the input statistics gathering thread - acquiring bitrates of elementary streams on inputs; the CLI thread - waiting for connections and responding to user's commands; and the PSI/SI processing thread - which requests capture of PSI/SI information from the input thread and then parses it accordingly.
Reliability was the most important consideration during development of dvbmux.
The principal design rule is to reduce maximally the amount of code that is executed without an active CLI user overlooking the system. Emphasis is put on careful review of that code, so that dvbmux is very unlikely to crash when no operator is logged in to the CLI. The user may further reduce the amount of code that is executed without supervision by turning off the PSI/SI decoder thread. It is anyway only useful for easier configuration of the multiplexer and can be disabled without any loss of functionality, once the core is configured.
In addition, to prevent memory leaks, the realtime multiplexing thread avoids allocating memory. The only exception is raising buffers up to a configured limit when it is necessary to prevent packet loss. The buffers can also be frozen by the user, so that no dynamic allocation occurs at all in the program, except for configuration sessions.
To minimize jitter, the multiplexer thread is output-oriented. Input packets are directed to appropriate buffers, according to the PID routing table, but their arrival itself causes no action on the output side. Instead, every running output stream triggers UDP packet generation events in regular time intervals (accordingly to its configured bitrate). Typically, only one packet per scheduling event is constructed from the input buffers and sent.
Please DO EXPECT some jitter emerging on all outputs when issuing any command that causes a reconfiguration of any of the inputs. On the other hand, no packets will be lost and unless some ancient (unbuffered) hardware is used to receive MPEG2 Transport Streams generated by dvbmux, no service disruption should occur on the outputs not affected by the reconfiguration.
As a matter of fact, jitter may even appear when doing extensive diagnostics using "show" commands.
Please use a DEDICATED server to process MPEG streams, ie. do not use virtual machines; do not run your company e-mail service on the same server. Remove all unnecessary crontab entries.
Make sure that kernel socket buffer size limits are set high, try eg.
# echo 5000000 > /proc/sys/net/core/rmem_default # echo 10000000 > /proc/sys/net/core/rmem_max
The performance limit of a particular hardware configuration the dvbmux runs can be pushed by using the output ... min-event N configuration command. It will cause the output packets to be generated in rapidly successing trains of N packets, thus trading off jitter for performance.
If you plan to use multicasts, decide which system interface should be the multicast content interface. This is done by configuring a static route to 224.0.0.0/4, say:
# ip route add 224.0.0.0/4 dev eth2
We have tested this software against bugs and memory leaks, however to ensure maximal reliability we recommend to disable the SI decoder when not needed (system si decoder disable) and re-enable it only during reconfiguration. This will cause the dvbmux to loop over a minimal amount of code, unless there is an active CLI connection.
Another, potentially dangerous code section is the PSI/SI descriptors' disassembling routine. Please refrain from using the show ... descriptors detailed command on mission critical systems. No descriptors are parsed or assembled without user request.
Please note that all CLI connections are handled in a single thread. If the CLI has something to output to a particular connection, it NEVER waits until the data is send. Instead, for every connection the output is buffered and gradually send. The connection buffers have a compiled-in limit (by default, 64k) and if a buffer overflow occurs, the connection is rapidly terminated. Such a situation may take place especially when a reply to a user-issued command weights more than 64k.
Please note that dvbmux is NOT free software. Please negotiate your licensing terms with:
Sileman Sp. z o.o. ul. Stara 15 PL-41703 Ruda Slaska POLAND (European Union) E-mail: software@sileman.pl