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
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:
- NET_ADD_IF
- NET_REMOVE_IF
- An additional ioctl (NET_GET_IF) allows developers to check the parameters of a given DVB interface.
Those ioctl system calls are described in the linux/dvb/net.h C header file as:
struct dvb_net_if {
__u16 pid;
__u16 if_num;
__u8 feedtype;
#define DVB_NET_FEEDTYPE_MPE 0 /* multi protocol encapsulation */
#define DVB_NET_FEEDTYPE_ULE 1 /* ultra lightweight encapsulation */
};
#define NET_ADD_IF _IOWR('o', 52, struct dvb_net_if)
#define NET_REMOVE_IF _IO('o', 53)
#define NET_GET_IF _IOWR('o', 54, struct dvb_net_if)
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:
# dvbnet -p 100 -a 0 -n 0 DVB Network Interface Manager Copyright (C) 2003, TV Files S.p.A Status: device dvb0_0 for pid 100 created successfully.
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:
# dvbnet -p 120 -a 0 -n 0 DVB Network Interface Manager Copyright (C) 2003, TV Files S.p.A Status: device dvb0_0 for pid 120 created successfully.
All mapped interfaces can be listed with:
$ sudo dvbnet -l DVB Network Interface Manager Copyright (C) 2003, TV Files S.p.A Query DVB network interfaces: ----------------------------- Found device 0: interface dvb0_0, listening on PID 100, encapsulation MPE Found device 1: interface dvb0_1, listening on PID 120, encapsulation MPE ----------------------------- Found 2 interface(s).
$ ip addr|grep -A1 dvb
3: dvb0_0: mtu 4096 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
4: dvb0_1: mtu 4096 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
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 maintainer of the Linux kernel media and EDAC subsystems, and also a major contributor for the Reliability Availability and Serviceability (RAS) subsystems. He has broad experience in both telecommunications and software development, from previous work in IT, network and management areas at Brazil's largest telecommunication operator. He also spent time at Red Hat maintaining the RHEL kernel. He currently works for the Samsung Open Source Group.
3万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
