May 28, 2015 - Mauro Carvalho Chehab

The Role of DTV Network Interfaces in Media Controller Support for DVB

Part 1 of this series can be read here.

Supporting embedded Digital TV (DTV) hardware is complex, considering that such hardware generally has multiple components that can each be rewired during runtime to dynamically change the stream pipelines and provide flexibility for activities like recording a video stream while tuning into another channel to watch a different program.

The first article of this series described how the Digital Video Broadcasting (DVB) pipelines are setup and the needs that should be addressed by the Linux Kernel. In this article, I’ll  discuss the needs of the DVB API with a focus on the network interfaces that are part of any DTV device.

An Introduction to Digital TV Network Interfaces

Typical DTV devices have dedicated hardware that provides the network interfaces. If you would like to learn more about such hardware, check out the first post in this series, specifically Figure 6 and Figure 7,  The data flow for these types of network interfaces can be seen below in Figure 1.

Figure 1: Digital TV embedded modem

Figure 1: Digital TV embedded modem

The Mux (Multiplexer) is used to combine multiple contents (like Internet data, VoIP data, program interaction commands, etc) into a single MPEG transport stream to carry information and send it back upstream. The Encoder is used to encode the transport stream under a physical channel that will be used to transmit the transport stream back to the service provider. These are typically only present on Cable TV hardware; consumer digital TV devices don’t usually have muxes or encoders. However, all digital TV hardware can provide network interfaces, and most of them have a unique Media Access Control (MAC) address just like any standard Ethernet device.

How DTV Network Interfaces are used

From the Linux API point of view, there are two input/output control (ioctl) system calls that control the creation and removal of the network interfaces, as described at The media Kernel API DocBook:

Those ioctl system calls are described in the linux/dvb/net.h C header file as:

The NET_ADD_IF ioctl system call selects the Packet ID (PID) that contains a TCP/IP traffic, the type of encapsulation to be used (either Multi Protocol Encapsulation (MPE) or Ultra Lightweight Encapsulation (ULE)) and the interface number for the new interface to be created. When the system call successfully returns, a new virtual network interface is  created.

For example, let’s imagine that PID 100 is used to control firmware updates on a given Set Top Box. In order to create an interface to handle TCP/IP traffic that comes via PID 100, using Digital TV adapter 0, demux 0, and  MPE encapsulation:

The new interface will be dvb0_0.

Let’s also imagine that PID 120 is used to provide Cable-TV based Internet access to the user. We need to create a second interface for this:

All mapped interfaces can be listed with:

Notice that the control device used to create both interfaces is: /dev/dvb/adapter0/net0. This device node is not actually associated with any traffic on the interface, rather its job is to control the demux hardware to filter the selected PIDs, and associate the decapsulation of the TCP/IP traffic at the hardware that handles the network interfaces. In this example, the actual data will go though the network virtual interfaces (dvb0_0 and dvb0_1).

Linux Kernel Media Controller to the Rescue!

Now that I’ve laid the foundation to fully understand embedded DTV pipelines and their network interfaces, the next step is to improve the Linux Kernel media controller in order to support such complex configurations. Upcoming posts in this series will describe how the Linux Kernel media controller is addressing DVB pipelines and the new functionality that is being added to make this happen.

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

Embedded Technology / Linux Digital TV / Linux TV / Multimidia / Smart TV /

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments Protected by WP-SpamShield Anti-Spam