May 8, 2015 - Mauro Carvalho Chehab
Media Controller Support for Digital Video Broadcasting
Supporting embedded Digital TV hardware is complex, considering that such hardware generally has multiple components that can be rewired in runtime to dynamically change the stream pipelines and provide flexibility for things like recording a video stream, then tuning into another channel to see a different program. This article describes how the DVB pipelines are setup and the needs that should be addressed by the Linux Kernel. This introduction will lead into the next article in this series, which will describe how the media subsystem is being improved to support such needs.
Digital TV devices
A Digital TV device consists of a set of hardware blocks. The basic components are:
Tuner – Tunes into a physical frequency (tuner), and outputs the channel on an Intermediate Frequency (IF).
Demodulator (a. k. a. demod) – Gets an IF, decodes the sub-carrier(s) content, and outputs the resulting MPEG-TS stream. It is specific for a given set of DTV standards.
Demultiplexer (a. k. a. demux) – Filters the MPEG-TS and extracts video, audio, and other data information, like subtitles, Electronic Program Guide, etc. The demux may also extract TCP/IP packets from the MPEG-TS and send them via a Linux network interface
Satellite devices also have a Satellite Equipment Control (SEC), which controls external components of the antenna subsystem like DiSEqC switches, LNBf, rotors, etc.
- Inexpensive/low-end devices don’t have a demux. The Linux Kernel emulates it in such cases.
- Some devices may have a MPEG-TS multiplexer (for TCP/IP data send) and Conditional Access Module support (for Digital Rights Management).
Digital TV Front End
The DTV front end consists of several sub-devices including tuner, demod, low noise amplifiers (LNBf, LNA) that can be coupled at the antenna system and SEC.
Its functions include:
- Tuning into a physical channel
- Demodulating the channel data
- Controlling the satellite and signal amplifiers
On Digital TV, tuning into a channel is a tightly-coupled operation:
- The IF used by the demod and tuner should be the same.
- The tuner filters should be optimized to the digital TV standard in use.
- On some devices, in order to increase the quality of the signal the demod should control the tuner and amplifier gain, and set bandwidth filters dynamically.
- On some satellite devices, the same hardware component will contain all 3 functions (tuner, demodulator and SEC).
- On many devices, a FPGA or micro-controller handles both tuner and demod. In such cases, the tuner is not directly visible, but instead, a higher-level API is exposed. Additionally the FPGA/firmware receives the frequency and other parameters via the front end, and commands the tuner together with the demod to obtain optimized tuning.
The Linux DVB API was designed to expose the front end as a single entity. Yet, it might be necessary to expose the sub-devices in the future to allow direct control of the tuner, SEC, and low noise amplifiers.
The basic structure of most digital TV standards is the MPEG Transport Stream (MPEG-TS). The Transport Stream is a mechanism of encapsulating and multiplexing several different streams into a single stream. Each individual stream is called an Elementary Stream, and is identified via unique Packet ID (PID), as shown in Figure 2.
Linux Kernel Digital TV APIs
There are several device nodes for Digital TV to control hardware components:
/dev/dvb/adapter?/frontend? – The Front End API controls the tuner, demod and SEC
/dev/dvb/adapter?/ca? – The CA API controls the conditional access module
/dev/dvb/adapter?/demux? – The demux API controls the demux
In addition, there are other device nodes, such as:
/dev/dvb/adapter?/dvr? – Controls the MPEG-TS filtered output
/dev/dvb/adapter?/net? – Controls the MPEG-TS filter for a network adapter
Digital TV data flow pipelines
The Linux DVB API is used to control data flow. The tuner and demod are typically hardwired, and filters are dynamically created/removed to setup a filtered MPEG-TS to become available to the user space via the DVB demux API. Each filter contains a PID (PES filter) or a section filter (to filter tables). The PID set that matches the filtering parameters is sent to the user space via the DVR device node, and eventually passes through a Conditional Access Module (CAM) to be decrypted. Another option is to send each individual PID to a per/PID file descriptor in the user space via the demux device node.
From data flow point of view, a typical Digital TV PC customer’s device looks like what’s shown at Figure 3:
Please note: On embedded hardware, the sink can actually be a GPU pipeline.
The control of the DVB device is done via several device nodes, as shown in Figure 4.
Several device nodes are used to control the hardware:
The front end devnode – controls tuner, demod (and SEC, for satellite)
The demux devnode – controls the demux
The CA devnode – controls the Conditional Access Module
Please notice that the DVR devnode doesn’t control anything – it is just used by read() ioctl to access the device data.
Other Examples of Digital TV Data Flows
The previous examples shown above are typical inexpensive PC hardware. On embedded devices, more complex data flows may happen, as shown in Figure 5 and Figure 6.
Figure 6 is actually simplified, as it doesn’t show the demod or demux and is based on a picture found here.
It can be challenging to get diagrams like these from the Internet, as the real STB designs are typically protected by Non-disclosure Agreements (NDA). Since we want to give a more real example, let’s extrapolate from the diagram shown in Figure 6 to build an example showing demux, CAM and demod hardware with cross-bars between most of the elements. The figure below allows us to randomly route to several alternatives.
Please note: Figure 7 doesn’t represent any real hardware; it is just an extrapolation from the diagram shown in Figure 6.
Now that the embedded Digital TV pipelines are understood, the next step is to improve the Linux Kernel in order to support such complex configurations. Before that, we still need to discuss an special case: network interfaces provided by Digital TV hardware.
On the next blog post in this series, I’ll describe the DVB network interfaces and how the Linux Kernel is addressing the DVB pipelines using the media controller.
Stay tuned!Image Credits: Derivative of work by Subcommandante
About Mauro Carvalho Chehab
Mauro is the upstream maintainer of the Linux kernel media and EDAC subsystems, and also a major contributor for the Reliability Availability and Serviceability (RAS) subsystems. Mauro also maintains Tizen on Yocto packages upstream. He works for the Samsung Open Source Group since 2013. Has worked during 5 years at the Red Hat RHEL Kernel team, having broad experience in telecommunications due to his work at some of the Brazilian largest wired and wireless carriers.
Image Credits: Derivative of work by Subcommandante