From version ... dvbmux supports local sources, in addition to UDP sockets. Local sources are configured similarly to UDP sources. Instead of providing the source IP address, a filesystem path must be provided. The path must start either with a slash (/) or a dot (.)
input example_local source /tmp/input.fifo
Since the source keyword accepts only a single word, in order to support paths with spaces and special characters, an additional file keyword is available, taking the input up to EOL as the file name.
dvbmux read()s greedily as much as there is available from every source. Whatever does not fit into the outputs is buffered. This is a very sane strategy for network inputs or for realtime local sources providing data at a limited rate (be it CBR or VBR).
However, when reading from files, the whole file contents is available for dvbmux at once. This means that without any futher configuration, specifyng an ordinary file as a local source will cause dvbmux to read it at maximal possible speed. Usually it will cause an immediate overflow of buffers of the group this input is directed to, and in turn, packet loss in that group. Since this reading will take all available processing power, other routing paths within the multiplexer will probably become affected as well.
In order to reasonably input transport streams from files to the multiplexer, one has to specify the reading speed. This is done by issuing input [name] local-source cbr [bits per second]. The following example configures the reading speed at 12 Mb/s:
input example_local local-source cbr 12000000
Note: when the reading speed is specified for a source, dvbmux takes care of it no more frequently than a certain number of milliseconds. Automatically, this interval is computed so that approx. 1024 MPEG packets are read at once from the source. The interval can, however, be changed manually by issuing input [name] local-source min-pause [ms]. Smaller intervals affect negatively dvbmux performance. On the contrary, large intervals may result in buffer overflows, and then, in turn, packet loss. By default, dvbmux allocates at most a 4096-packet buffer for every group; this can however be changed using system max-buffer-size command.
Again, please note that configuring the reading speed is not necessary when reading from a realtime source (such as a character device).
Internally, dvbmux reads local sources in the same loop the UDP sources are read(). There are, however, a few slight differences in handling their error conditions, as compared to UDP inputs.
First of all, when an EOF is encountered on a local source, the source is close()d and (asynchronously!) re-opened. Should there be a problem on re-opening the source, dvbmux will retry every 100 ms.
The second difference concerns loss of sync. In case of UDP sources, incorrect sync bytes simply cause dvbmux to skip 188 bytes in the input stream. Whatever the condition was triggered by, dvbmux simply hopes that upon reception of next packet, the sync word will be aligned to the packet boundary (start of new received packet).
On the contrary, when sync is lost in a local stream, dvbmux attempts to re-sync. At first, the sync word is looked for in the available input buffer. This means it will be looked for in at least 188 and at most 1315 bytes ahead of the position where the original sync word failed to appear. If this succeeds, bytes preceding the found syncword are discarded and an additional read() of at most 187 bytes is made, so that the input buffer contains an even number of MPEG packets. Processing then resumes, although one MPEG packet (starting with the newly found syncword) is skipped.
When the sync word cannot be found within the read() buffer, dvbmux close()s the source and asynchronously reopens it. Again, if an error occurs during this reopen, next attempts are made infinitely every 100 ms.
Please note that dvbmux provides a 1316-byte buffer to read(). While it does not rely on the buffer being completely filled, it does expect the read result to contain complete MPEG packets (eg. no packets split in half between subsequent read()s). If this condition is not met, loss of packets and desyncs will occur. This is not a problem when reading from files or FIFOs, however might be an issue in case of certain special devices or filesystems, depending on the kernel side implementation (ie. in case the data comes packetized in chunks not being 188 bytes or a multiple of 188 bytes long).
When configuring an input, dvbmux raises an error condition if it cannot obtain a file descriptor providing its source. This is particularly important on startup. If the saved configuration refers to a local source that cannot be open()ed on dvbmux startup, configuration of that source will fail completely and during operation, dvbmux will not attempt reconnecting every 100 ms (contrary to error conditions occuring after the configuration is made!). In future it is possible that a commandline keyword will be added to express a desire to create an input even if data cannot be sourced at the moment of configuration.