** The ''frontend'' character device controls the [[tuner]] and [[demodulator]] hardware ... (Note: there are different types of these hardware components for the different [[Digital Video Broadcasting|DTV standards]])

** The ''frontend'' character device controls the [[tuner]] and [[demodulator]] hardware ... (Note: there are different types of these hardware components for the different [[Digital Video Broadcasting|DTV standards]])

* ''demux''

* ''demux''

−

** The ''demux'' character device controls the filters for processing the [[Transport Stream|transport stream]] (TS).

+

** The ''demux'' character device controls the filters for processing the [[Transport Stream|transport stream]] (TS). In essence, the demultiplexer splits the TS into its component parts (which usually entail being several audio and video streams, as well as some data streams)

*** ''dvr''

*** ''dvr''

−

**** The ''dvr'' is a logical device that is associated with the demux character device ... it delivers up the TS for either:

+

**** The ''dvr'' is a logical device that is associated with the demux character device ... it delivers up a TS that was multiplexed from the sub-streams specified and filtered, from the original TS, by the demux for either:

::::(1) immediate playback --- in which case it has to be decoded either:

::::(1) immediate playback --- in which case it has to be decoded either:

::::: a) on the device itself ... [now days its quite rare for PC devices to have hardware decoding ([[Hardware or Software Decoder?|see discussion]]), but this is certainly not the case for [[STB]]s)

::::: a) on the device itself ... [now days its quite rare for PC devices to have hardware decoding ([[Hardware or Software Decoder?|see discussion]]), but this is certainly not the case for [[STB]]s)

Line 29:

Line 29:

::::or

::::or

::::(2) saving to disk for later playback.

::::(2) saving to disk for later playback.

+

:In essence, the ''demux'' decomposes the original TS and selects/filters particular underlining sub-streams and the dvr then repackages those selections within a TS. Typically the multiplexed TS provided by the ''dvr'' would be composed of an individual program stream

* ''net''

* ''net''

−

** The ''net'' character device controls the ability to provide IP-over-DVB (i.e. satellite based internet service)

+

** The ''net'' character device controls the ability to provide IP-over-DVB (e.g. satellite based broadband internet service ... Note: although it is not mentioned in the [http://linuxtv.org/downloads/v4l-dvb-apis/ch14.html API documentation], this functionality is not restricted to satellite (DVB-S) alone -- any DVB capable device can support it, provided you use the dvb net module (i.e. it is possible over DVB-C and DVB-T as well). The dvbnet script in the [[LinuxTV dvb-apps|dvb-apps]] handles this. As an example, both Scientific Atlantic and Cisco have DVB STB devices which can provide such broadband services.)

* ''video''

* ''video''

** The ''video'' character device controls the MPEG2 video decoder of the DVB hardware (if present ... found on so called "[[Full-featured Card#(i) "Full-Featured" or "Premium" Cards|full-featured device]]s") .... Note: do NOT confuse this with the video character device created by V4L devices (see the [[Device nodes and character devices#V4L_character_devices|discussion below]]), as they are entirely different things. Specifically, the DVB video character device only controls decoding of the MPEG video stream, not its presentation on the computer or TV screen. This later function, on a full-featured device, is typically handled by an associated video4linux device IC, which allows scaling and defining output windows. Control of this later device is established through a V4L character device, specifically, ''/dev/video''.

** The ''video'' character device controls the MPEG2 video decoder of the DVB hardware (if present ... found on so called "[[Full-featured Card#(i) "Full-Featured" or "Premium" Cards|full-featured device]]s") .... Note: do NOT confuse this with the video character device created by V4L devices (see the [[Device nodes and character devices#V4L_character_devices|discussion below]]), as they are entirely different things. Specifically, the DVB video character device only controls decoding of the MPEG video stream, not its presentation on the computer or TV screen. This later function, on a full-featured device, is typically handled by an associated video4linux device IC, which allows scaling and defining output windows. Control of this later device is established through a V4L character device, specifically, ''/dev/video''.

Line 54:

Line 55:

<code>ls -l /dev/v4l</code>

<code>ls -l /dev/v4l</code>

What you should find in that '''device node''' is a sub directory, named "by-path", that contains symbolic links to '''character device''' files, whose conventional names and functions are summarized in the table below.

What you should find in that '''device node''' is a sub directory, named "by-path", that contains symbolic links to '''character device''' files, whose conventional names and functions are summarized in the table below.

+

{{Note|You can determine which device maps to ''videoN'' by matching, for example (in the case of a pci card), the domain:bus:slot.func information provided by the command lspci to the associated links in the by-path directory .... Somewhat similarly, QUERYCAP ioctl() or sysfs can be used to expose which V4L driver maps to ''videoN'' [http://www.mail-archive.com/linux-media@vger.kernel.org/msg70058.html] }}

Contents

For a DVB device

A properly loaded device module should result in a non-empty /dev/dvb directory. You can check on whether this is true with the following command:

ls -l /dev/dvb/

(alternatively, you can browse your directory structure with the graphical file manager of your choice). More specifically, the output of the above command should reveal that /dev/dvb/ is populated by "adapterN" (whereby, in terms of enumerating the devices installed in the system, N=0 to whatever 1). For example, if you have but a single DVB device installed in your system, then expect to find /dev/dvb/adapter0.

DVB character devices

The Linux DVB API provides for six unix style character devices which allow control of the hardware components found on a particular DVB device adapter.It is under each adapterN directory that you will find these character devices. The command

ls -l /dev/dvb/adapter0

reveals the character devices associated with adapter0 for which the drivers have control. If you have more then one DVB device, you can see the same for all with

ls -l /dev/dvb/adapter*

Similar to the way in which the device adapters are enumerated, the character devices follow the form of M=0 to whatever 1. For example: /dev/dvb/adapter0/frontend0 .... if the same device had a second frontend, that character device would be enumerated by /dev/dvb/adapter0/frontend1 ... if you had another dvb adapter in the system, then you would see /dev/dvb/adapter1/frontend0 and so forth.

In brief, these character devices are:

frontend

The frontend character device controls the tuner and demodulator hardware ... (Note: there are different types of these hardware components for the different DTV standards)

demux

The demux character device controls the filters for processing the transport stream (TS). In essence, the demultiplexer splits the TS into its component parts (which usually entail being several audio and video streams, as well as some data streams)

dvr

The dvr is a logical device that is associated with the demux character device ... it delivers up a TS that was multiplexed from the sub-streams specified and filtered, from the original TS, by the demux for either:

(1) immediate playback --- in which case it has to be decoded either:

a) on the device itself ... [now days its quite rare for PC devices to have hardware decoding (see discussion), but this is certainly not the case for STBs)

or

b) downstream by the system [the usual route for PC devices -- i.e. software decoding via the host CPU, and possibly assisted by the GPU ... (see here for more discussion) ]

or

(2) saving to disk for later playback.

In essence, the demux decomposes the original TS and selects/filters particular underlining sub-streams and the dvr then repackages those selections within a TS. Typically the multiplexed TS provided by the dvr would be composed of an individual program stream

net

The net character device controls the ability to provide IP-over-DVB (e.g. satellite based broadband internet service ... Note: although it is not mentioned in the API documentation, this functionality is not restricted to satellite (DVB-S) alone -- any DVB capable device can support it, provided you use the dvb net module (i.e. it is possible over DVB-C and DVB-T as well). The dvbnet script in the dvb-apps handles this. As an example, both Scientific Atlantic and Cisco have DVB STB devices which can provide such broadband services.)

video

The video character device controls the MPEG2 video decoder of the DVB hardware (if present ... found on so called "full-featured devices") .... Note: do NOT confuse this with the video character device created by V4L devices (see the discussion below), as they are entirely different things. Specifically, the DVB video character device only controls decoding of the MPEG video stream, not its presentation on the computer or TV screen. This later function, on a full-featured device, is typically handled by an associated video4linux device IC, which allows scaling and defining output windows. Control of this later device is established through a V4L character device, specifically, /dev/video.

osd

The osd character device is not documented in the API, but it stems from the legacy OSD API for so called "full-featured devices". The draft version of the never finished v4 Linux DVB API makes passing mention of this character device: "The Linux DVB API Version 3 was focussed on the popular Siemens PCI DVB card. Due to the pragmatic evolution of the API, there are namespace inconsitencies and inconsitent remains of things that really don’t belong into the API, like ad-hoc DVD subtitle support or a very limited OSD API design." Nonetheless, when dealing with a full-featured card, it will indeed show up under the adapter node, as illustrated by this end user supplied example.

audio

The audio character device controls the MPEG2 audio decoder of the DVB hardware (if present ... found on so called full-featured devices")

Not all of the character devices defined by the DVB API need be present for a device, specifically because some functionality is not needed; in point:

Most DVB devices don’t have their own MPEG decoder because:

modern CPUs and the ability to offload decoding to video card GPUs has pretty much long replaced the need of the so called "full feautred" class of DVB devices, or

may be foregone for datacasting type devices (e.g. for data-only uses like “internet over satellite”)

In any regard, for either reason, this results in the omission of the audio and video character devices

Not every device or STB provides conditional access hardware ... i.e. leads to the omission of the ca character device

The DVB API may also be used for MPEG decoder-only PCI cards, in which case, for these rare devices, there exists no need for the frontend character device

In fact, a typical DVB device these days will usually only contain three of these character devices (frontend, demux, net), as well as the special logical device (dvr).

For a V4L device

Similarly, with "V4L devices", a properly loaded device module should result in a non-empty /dev/v4l directory. You can check on whether this is true with the following command:

ls -l /dev/v4l

What you should find in that device node is a sub directory, named "by-path", that contains symbolic links to character device files, whose conventional names and functions are summarized in the table below.

Note: You can determine which device maps to videoN by matching, for example (in the case of a pci card), the domain:bus:slot.func information provided by the command lspci to the associated links in the by-path directory .... Somewhat similarly, QUERYCAP ioctl() or sysfs can be used to expose which V4L driver maps to videoN[1]

V4L character devices

The V4L2 API defines three special character devices. In the table below, and ensuing discussion, we make note of a fourth, the Teletext Interface, which was defined by the older V4L1 API, but is not, nor intended to be, defined in the newer V4L2 API. This fourth character device does, however, receive de facto support given that "for compatibility reasons the character device file names recommended for V4L2 video capture, overlay, radio, teletext and raw vbi capture devices did not change from those used by V4L" and can be serviced "through the V4L2 compatibility layer in the videodev kernel module". 2

The most prominently recognized are the /dev/videoN character devices (whereby, in terms of enumerating the devices installed in the system, N=0 to whatever 1). You can check for them within your system with the following command:

ls -l /dev/video*

A more detailed explanation of the V4L character devices are outlined in point form below:

Video Overlay Interface (also known as Framebuffer Overlay or Previewing)

accessed through the same character special files as video capture devices.

Note the default function of a /dev/video device is video capturing. The overlay function is only available after calling the VIDIOC_S_FMT ioctl.

Video Output Interface

Video output devices encode stills or image sequences as analog video signal. With this interface applications can control the encoding process and move images from user space to the driver.

Video Output Overlay Interface

Some video output devices can overlay a framebuffer image onto the outgoing video signal. Applications can set up such an overlay using this interface, which borrows structures and ioctls of the Video Overlay interface.

The OSD function is accessible through the same character special file as the Video Output function. Note the default function of such a /dev/video device is video capturing or output. The OSD function is only available after calling the VIDIOC_S_FMT ioctl.

Framebuffer

Contrary to the Video Overlay interface the framebuffer is normally implemented on the TV card and not the graphics card. On Linux it is accessible as a framebuffer device (/dev/fbN). Given a V4L2 device, applications can find the corresponding framebuffer device by calling the VIDIOC_G_FBUF ioctl.

/dev/radio

Radio Interface

accessed through character device special files named /dev/radio and /dev/radio0 to /dev/radio63 with major number 81 and minor numbers 64 to 127. Note that /dev/radio is a symbolic link to /dev/radio03

VBI capturing and output is also available as device function under /dev/video. To capture or output raw VBI data with these devices applications must call the VIDIOC_S_FMT ioctl. Accessed as /dev/vbi, raw VBI capturing or output is the default device function.

Sliced VBI Data Interface

Sliced VBI devices use hardware to demodulate data transmitted in the VBI. V4L2 drivers shall not do this by software, see also the raw VBI interface.

Sliced VBI capture and output devices are accessed through the same character special files as raw VBI devices.

When a driver supports both VBI interfaces, the default function of a /dev/vbi device is raw VBI capturing or output, and the sliced VBI function is only available after calling the VIDIOC_S_FMT ioctl

Likewise a /dev/video device may support the sliced VBI API, however the default function here is video capturing or output.

Not all of the character devices defined by the V4L2 API need be present for a device, specifically because some functionality is not needed or present on the device. For example, unless the device contains a decoder IC for AM/FM radio reception, the /dev/radio character device need not be created by the driver.

Associated Nodes and Character Devices for Analog Audio Input/Output

/dev/mixer

/dev/dsp

Endnotes

Note 1: The real life limitation of the "whatever" comment is given by the max. adapter definition in the respective device driver (Note: this is usually set at 8, though, this can be adjusted for more by altering the source code and recompiling. Also note that a patch was submitted in Sept/09, which will allow configuration of the max adapter definition)

Note 2: The V4L2 API clearly denotes, in the case of the three defined character devices, that the respective base is a symbolic link to the respective N=0 character device (i.e. /dev/video --> /dev/video0). For the video and radio character devices, this is also cited within the {Linux}/Documentation/devices.txt file

Note 4: While no mention of it is made in the V4l2 API, presumably the base /dev/vtx character device is a symbolic link to /dev/vtx0; as this would be similar in case with the three defined character devices.

Also See

For more comprehensive information, it is suggested that you review the DVB and V4L APIs

For more comprehensive information on the associated audio nodes, it is suggested that you review ALSA and/or OSS related materials