DemuxFS is a live filesystem that aids on the analysis of transport streams in digital TV systems. At the root of the filesystem, directories are created for each table in the transport stream, such as PMT, PAT, NIT, SDTT, and EIT. Inside these directories, virtual files reflect the many properties of these tables.
Packetized Elementary Streams (PES), which hold audio, video and data, are represented in DemuxFS as FIFOs. Through FIFOs, users can playback specific audio and video streams and inspect the contents of closed-caption streams. DemuxFS also handles the protocol stack of DSM-CC, allowing for the seamless inspection of interactive applications.
DemuxFS supports the SBTVD, ISDB, DVB and ATSC standards.
DemuxFS comes with two backends:
-
filesrc: lets you inspect a transport stream captured in a file
-
linuxdvb: lets you inspect a live transport stream through the LinuxDVB stack
This is how you invoke DemuxFS to analyze the contents of a file. The directory at /Mount/DemuxFS
will be populated with the data parsed from that file:
demuxfs -o backend=filesrc -o filesrc=/path/to/file /Mount/DemuxFS
You can also let DemuxFS continuously parse a file with the fileloop option:
demuxfs -o backend=filesrc -o filesrc=/path/to/file -o fileloop=-1 /Mount/DemuxFS
By default, the LinuxDVB backend will attempt to configure the frontend0, demux0, and dvr0 devices under /dev/dvb/adapter0
. If the frontend has been already tuned to a frequency by a third party program, then you can simply run:
demuxfs -o backend=linuxdvb /Mount/DemuxFS
DemuxFS can tune the frontend to a specified frequency, given in Hz, with:
demuxfs -o backend=linuxdvb -o frequency=527142857 /Mount/DemuxFS
The full list of options supported by this backend is given by demuxfs --help
Once the transport stream has been mounted, its contents can be inspected with regular system utilities such as ls
, cat
, and getfattr
. The mount point holds one directory for each MPEG-2 TS table parsed by DemuxFS:
When broadcasters need to announce changes to a program, they do so by sending a new version of a given table. DemuxFS records all versions received so far under different subdirectories. A symbolic link indicates the current version being broadcasted:
Table members are stored as regular files and directories. The data format of each file is given by the system.format extended attribute:
In the MPEG-2 TS (transport stream), the PAT table announces the identification of the programs being broadcasted. The details of these programs are found in the PMT table(s). The PAT also announces the id of the current network (usually holding details about the broadcaster). For convenience, DemuxFS represents those as symbolic links to the PMT and NIT tables:
AudioStreams
and VideoStreams
may hold more than one subdirectory each, as in programs with multiple camera angles or audio tracks. In that case, symbolic links named Primary
and Secondary
will designate the primary and secondary stream ids that applications are expected to use by default. Directories with all capital letters (such as PARENTAL_RATING_0
) represent table descriptors featured in the transport stream.
Packetized elementary streams are data packets that include a header and a payload (often an audio, video, or caption stream). Elementary streams are the actual payload. Both are presented in DemuxFS as FIFO files. That is, one can inspect them with e.g., hexdump
or reproduce them with e.g., ffplay
and mplayer
.
DemuxFS also generates a preview of the video frame being currently received (or parsed) on-the-fly. When snapshot.gif
is opened by an application, DemuxFS internally feeds FFmpeg with the elementary stream data and copies the rendered frame back to that application.
This is how the contents of a H.264 video stream program look like:
Note that you need to invoke DemuxFS with -o parse_pes=1
to enable still picture previews and raw access to the elementary stream.
DemuxFS also handles the protocol stack of DSM-CC, which implements data and object carousels. All related tables (AIT, DII, DSI, and DDB) are exported to the filesystem. Besides, the actual data blocks are decoded and exported to the filesystem as regular files and directories. By doing so, users can inspect the contents of interactive applications and firmware updates. The decoded data is stored in the mount point's DSM-CC
directory.