Copyright © 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin Rubli
This document is copyrighted © 1999-2007 by Bill Dirks, Michael H. Schimek, Hans Verkuil and Martin Rubli.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the appendix entitled "GNU Free Documentation License".
Programming examples can be used and distributed without restrictions.
V4L2_PIX_FMT_YUYV with different order of samples
in memoryV4L2_PIX_FMT_YUYVV4L2_PIX_FMT_Y41PV4L2_PIX_FMT_YVU420V4L2_PIX_FMT_BGR24 4 × 4 pixel
imageV4L2_PIX_FMT_SBGGR8 4 × 4
pixel imageV4L2_PIX_FMT_GREY 4 × 4
pixel imageV4L2_PIX_FMT_YUYV 4 × 4
pixel imageV4L2_PIX_FMT_UYVY 4 × 4
pixel imageV4L2_PIX_FMT_Y41P 8 × 4
pixel imageV4L2_PIX_FMT_YVU420 4 × 4
pixel imageV4L2_PIX_FMT_YVU410 4 × 4
pixel imageV4L2_PIX_FMT_YUV422P 4 × 4
pixel imageV4L2_PIX_FMT_YUV411P 4 × 4
pixel imageV4L2_PIX_FMT_NV12 4 × 4
pixel imageVideo For Linux Two is the second version of the Video For Linux API, a kernel interface for analog radio and video capture and output drivers.
Early drivers used ad-hoc interfaces. These were replaced in Linux 2.2 by Alan Cox' V4L API, based on the interface of the bttv driver. In 1999 Bill Dirks started the development of V4L2 to fix some shortcomings of V4L and to support a wider range of devices. The API was revised again in 2002 prior to its inclusion in Linux 2.5/2.6, and work continues on improvements and additions while maintaining compatibility with existing drivers and applications. In 2006/2007 efforts began on FreeBSD drivers with a V4L2 interface.
This book documents the V4L2 API. Intended audience are driver and application writers.
If you have questions or ideas regarding the API, please write to the Video4Linux mailing list: https://listman.redhat.com/mailman/listinfo/video4linux-list. For inquiries about the V4L2 specification contact the maintainer mschimek@gmx.at.
The latest version of this document and the DocBook SGML sources are hosted at http://v4l2spec.bytesex.org, and http://linuxtv.org/downloads/video4linux/API/V4L2_API.
Programming a V4L2 device consists of these steps:
Opening the device
Changing device properties, selecting a video and audio input, video standard, picture brightness a. o.
Negotiating a data format
Negotiating an input/output method
The actual input/output loop
Closing the device
In practice most steps are optional and can be executed out of order. It depends on the V4L2 device type, you can read about the details in Chapter 4. In this chapter we will discuss the basic concepts applicable to all devices.
V4L2 drivers are implemented as kernel modules, loaded manually by the system administrator or automatically when a device is first opened. The driver modules plug into the "videodev" kernel module. It provides helper functions and a common application interface specified in this document.
Each driver thus loaded registers one or more device nodes with major number 81 and a minor number between 0 and 255. Assigning minor numbers to V4L2 devices is entirely up to the system administrator, this is primarily intended to solve conflicts between devices.[1] The module options to select minor numbers are named after the device special file with a "_nr" suffix. For example "video_nr" for /dev/video video capture devices. The number is an offset to the base minor number associated with the device type. [2] When the driver supports multiple devices of the same type more than one minor number can be assigned, separated by commas:
In /etc/modules.conf this may be written as:
alias char-major-81-0 mydriver alias char-major-81-1 mydriver alias char-major-81-64 mydriveroptions mydriver video_nr=0,1 radio_nr=0,1
![]()


By convention system administrators create various character device special files with these major and minor numbers in the /dev directory. The names recomended for the different V4L2 device types are listed in Chapter 4.
The creation of character special files (with mknod) is a privileged operation and devices cannot be opened by major and minor number. That means applications cannot reliable scan for loaded or installed drivers. The user must enter a device name, or the application can try the conventional device names.
Under the device filesystem (devfs) the minor number options are ignored. V4L2 drivers (or by proxy the "videodev" module) automatically create the required device files in the /dev/v4l directory using the conventional device names above.
Devices can support several related functions. For example video capturing, video overlay and VBI capturing are related because these functions share, amongst other, the same video input and tuner frequency. V4L and earlier versions of V4L2 used the same device name and minor number for video capturing and overlay, but different ones for VBI. Experience showed this approach has several problems[3], and to make things worse the V4L videodev module used to prohibit multiple opens of a device.
As a remedy the present version of the V4L2 API relaxed the concept of device types with specific names and minor numbers. For compatibility with old applications drivers must still register different minor numbers to assign a default function to the device. But if related functions are supported by the driver they must be available under all registered minor numbers. The desired function can be selected after opening the device as described in Chapter 4.
Imagine a driver supporting video capturing, video
overlay, raw VBI capturing, and FM radio reception. It registers three
devices with minor number 0, 64 and 224 (this numbering scheme is
inherited from the V4L API). Regardless if
/dev/video (81, 0) or
/dev/vbi (81, 224) is opened the application can
select any one of the video capturing, overlay or VBI capturing
functions. Without programming (e. g. reading from the device
with dd or cat)
/dev/video captures video images, while
/dev/vbi captures raw VBI data.
/dev/radio (81, 64) is invariable a radio device,
unrelated to the video functions. Being unrelated does not imply the
devices can be used at the same time, however. The open()
function may very well return an EBUSY error code.
Besides video input or output the hardware may also support audio sampling or playback. If so, these functions are implemented as OSS or ALSA PCM devices and eventually OSS or ALSA audio mixer. The V4L2 API makes no provisions yet to find these related devices. If you have an idea please write to the Video4Linux mailing list: https://listman.redhat.com/mailman/listinfo/video4linux-list.
In general, V4L2 devices can be opened more than once. When this is supported by the driver, users can for example start a "panel" application to change controls like brightness or audio volume, while another application captures video and audio. In other words, panel applications are comparable to an OSS or ALSA audio mixer application. When a device supports multiple functions like capturing and overlay simultaneously, multiple opens allow concurrent use of the device by forked processes or specialized applications.
Multiple opens are optional, although drivers should
permit at least concurrent accesses without data exchange, i. e. panel
applications. This implies open() can return an EBUSY error code when the
device is already in use, as well as ioctl() functions initiating
data exchange (namely the VIDIOC_S_FMT ioctl), and the read()
and write() functions.
Mere opening a V4L2 device does not grant exclusive access.[4] Initiating data exchange however assigns the right to read or write the requested type of data, and to change related properties, to this file descriptor. Applications can request additional access privileges using the priority mechanism described in Section 1.3.
V4L2 drivers should not support multiple applications reading or writing the same data stream on a device by copying buffers, time multiplexing or similar means. This is better handled by a proxy application in user space. When the driver supports stream sharing anyway it must be implemented transparently. The V4L2 API does not specify how conflicts are solved.
To open and close V4L2 devices applications use the
open() and close() function, respectively. Devices are
programmed using the ioctl() function as explained in the
following sections.
Because V4L2 covers a wide variety of devices not all aspects of the API are equally applicable to all types of devices. Furthermore devices of the same type have different capabilities and this specification permits the omission of a few complicated and less important parts of the API.
The VIDIOC_QUERYCAP ioctl is available to check if the kernel
device is compatible with this specification, and to query the functions and I/O
methods supported by the device. Other features can be queried
by calling the respective ioctl, for example VIDIOC_ENUMINPUT
to learn about the number, types and names of video connectors on the
device. Although abstraction is a major objective of this API, the
ioctl also allows driver specific applications to reliable identify
the driver.
All V4L2 drivers must support
VIDIOC_QUERYCAP. Applications should always call
this ioctl after opening the device.
When multiple applications share a device it may be desirable to assign them different priorities. Contrary to the traditional "rm -rf /" school of thought a video recording application could for example block other applications from changing video controls or switching the current TV channel. Another objective is to permit low priority applications working in background, which can be preempted by user controlled applications and automatically regain control of the device at a later time.
Since these features cannot be implemented entirely in user
space V4L2 defines the VIDIOC_G_PRIORITY and VIDIOC_S_PRIORITY
ioctls to request and query the access priority associate with a file
descriptor. Opening a device assigns a medium priority, compatible
with earlier versions of V4L2 and drivers not supporting these ioctls.
Applications requiring a different priority will usually call
VIDIOC_S_PRIORITY after verifying the device with
the VIDIOC_QUERYCAP ioctl.
Ioctls changing driver properties, such as VIDIOC_S_INPUT,
return an EBUSY error code after another application obtained higher priority.
An event mechanism to notify applications about asynchronous property
changes has been proposed but not added yet.
Video inputs and outputs are physical connectors of a device. These can be for example RF connectors (antenna/cable), CVBS a.k.a. Composite Video, S-Video or RGB connectors. Only video and VBI capture devices have inputs, output devices have outputs, at least one each. Radio devices have no video inputs or outputs.
To learn about the number and attributes of the
available inputs and outputs applications can enumerate them with the
VIDIOC_ENUMINPUT and VIDIOC_ENUMOUTPUT ioctl, respectively. The
struct v4l2_input returned by the VIDIOC_ENUMINPUT
ioctl also contains signal status information applicable when the
current video input is queried.
The VIDIOC_G_INPUT and VIDIOC_G_OUTPUT ioctl return the
index of the current video input or output. To select a different
input or output applications call the VIDIOC_S_INPUT and
VIDIOC_S_OUTPUT ioctl. Drivers must implement all the input ioctls
when the device has one or more inputs, all the output ioctls when the
device has one or more outputs.
Example 1-1. Information about the current video input
struct v4l2_input input; int index; if (-1 == ioctl (fd,VIDIOC_G_INPUT, &index)) { perror ("VIDIOC_G_INPUT"); exit (EXIT_FAILURE); } memset (&input, 0, sizeof (input)); input.index = index; if (-1 == ioctl (fd,VIDIOC_ENUMINPUT, &input)) { perror ("VIDIOC_ENUMINPUT"); exit (EXIT_FAILURE); } printf ("Current input: %s\n", input.name);
Example 1-2. Switching to the first video input
int index;
index = 0;
if (-1 == ioctl (fd, VIDIOC_S_INPUT, &index)) {
perror ("VIDIOC_S_INPUT");
exit (EXIT_FAILURE);
}
Audio inputs and outputs are physical connectors of a device. Video capture devices have inputs, output devices have outputs, zero or more each. Radio devices have no audio inputs or outputs. They have exactly one tuner which in fact is an audio source, but this API associates tuners with video inputs or outputs only, and radio devices have none of these.[5] A connector on a TV card to loop back the received audio signal to a sound card is not considered an audio output.
Audio and video inputs and outputs are associated. Selecting
a video source also selects an audio source. This is most evident when
the video and audio source is a tuner. Further audio connectors can
combine with more than one video input or output. Assumed two
composite video inputs and two audio inputs exist, there may be up to
four valid combinations. The relation of video and audio connectors
is defined in the audioset field of the
respective struct v4l2_input or struct v4l2_output, where each bit represents
the index number, starting at zero, of one audio input or output.
To learn about the number and attributes of the
available inputs and outputs applications can enumerate them with the
VIDIOC_ENUMAUDIO and VIDIOC_ENUMAUDOUT ioctl, respectively. The
struct v4l2_audio returned by the VIDIOC_ENUMAUDIO ioctl
also contains signal status information applicable when the current
audio input is queried.
The VIDIOC_G_AUDIO and VIDIOC_G_AUDOUT ioctl report
the current audio input and output, respectively. Note that, unlike
VIDIOC_G_INPUT and VIDIOC_G_OUTPUT these ioctls return a structure
as VIDIOC_ENUMAUDIO and
VIDIOC_ENUMAUDOUT do, not just an index.
To select an audio input and change its properties
applications call the VIDIOC_S_AUDIO ioctl. To select an audio
output (which presently has no changeable properties) applications
call the VIDIOC_S_AUDOUT ioctl.
Drivers must implement all input ioctls when the device
has one or more inputs, all output ioctls when the device has one
or more outputs. When the device has any audio inputs or outputs the
driver must set the V4L2_CAP_AUDIO flag in the
struct v4l2_capability returned by the VIDIOC_QUERYCAP ioctl.
Example 1-3. Information about the current audio input
struct v4l2_audio audio;
memset (&audio, 0, sizeof (audio));
if (-1 == ioctl (fd, VIDIOC_G_AUDIO, &audio)) {
perror ("VIDIOC_G_AUDIO");
exit (EXIT_FAILURE);
}
printf ("Current input: %s\n", audio.name);
Example 1-4. Switching to the first audio input
struct v4l2_audio audio;
memset (&audio, 0, sizeof (audio)); /* clear audio.mode, audio.reserved */
audio.index = 0;
if (-1 == ioctl (fd, VIDIOC_S_AUDIO, &audio)) {
perror ("VIDIOC_S_AUDIO");
exit (EXIT_FAILURE);
}
Video input devices can have one or more tuners
demodulating a RF signal. Each tuner is associated with one or more
video inputs, depending on the number of RF connectors on the tuner.
The type field of the respective
struct v4l2_input returned by the VIDIOC_ENUMINPUT ioctl is set to
V4L2_INPUT_TYPE_TUNER and its
tuner field contains the index number of
the tuner.
Radio devices have exactly one tuner with index zero, no video inputs.
To query and change tuner properties applications use the
VIDIOC_G_TUNER and VIDIOC_S_TUNER ioctl, respectively. The
struct v4l2_tuner returned by VIDIOC_G_TUNER also
contains signal status information applicable when the tuner of the
current video input, or a radio tuner is queried. Note that
VIDIOC_S_TUNER does not switch the current tuner,
when there is more than one at all. The tuner is solely determined by
the current video input. Drivers must support both ioctls and set the
V4L2_CAP_TUNER flag in the struct v4l2_capability
returned by the VIDIOC_QUERYCAP ioctl when the device has one or
more tuners.
Video output devices can have one or more modulators, uh,
modulating a video signal for radiation or connection to the antenna
input of a TV set or video recorder. Each modulator is associated with
one or more video outputs, depending on the number of RF connectors on
the modulator. The type field of the
respective struct v4l2_output returned by the VIDIOC_ENUMOUTPUT ioctl is
set to V4L2_OUTPUT_TYPE_MODULATOR and its
modulator field contains the index number
of the modulator. This specification does not define radio output
devices.
To query and change modulator properties applications use
the VIDIOC_G_MODULATOR and VIDIOC_S_MODULATOR ioctl. Note that
VIDIOC_S_MODULATOR does not switch the current
modulator, when there is more than one at all. The modulator is solely
determined by the current video output. Drivers must support both
ioctls and set the V4L2_CAP_TUNER (sic) flag in
the struct v4l2_capability returned by the VIDIOC_QUERYCAP ioctl when the
device has one or more modulators.
To get and set the tuner or modulator radio frequency
applications use the VIDIOC_G_FREQUENCY and VIDIOC_S_FREQUENCY
ioctl which both take a pointer to a struct v4l2_frequency. These ioctls
are used for TV and radio devices alike. Drivers must support both
ioctls when the tuner or modulator ioctls are supported, or
when the device is a radio device.
To be discussed. See also proposals by Peter Schlaf, video4linux-list@redhat.com on 23 Oct 2002, subject: "Re: [V4L] Re: v4l2 api".
Video devices typically support one or more different video
standards or variations of standards. Each video input and output may
support another set of standards. This set is reported by the
std field of struct v4l2_input and
struct v4l2_output returned by the VIDIOC_ENUMINPUT and
VIDIOC_ENUMOUTPUT ioctl, respectively.
V4L2 defines one bit for each analog video standard
currently in use worldwide, and sets aside bits for driver defined
standards, e. g. hybrid standards to watch NTSC video tapes on PAL TVs
and vice versa. Applications can use the predefined bits to select a
particular standard, although presenting the user a menu of supported
standards is preferred. To enumerate and query the attributes of the
supported standards applications use the VIDIOC_ENUMSTD ioctl.
Many of the defined standards are actually just variations of a few major standards. The hardware may in fact not distinguish between them, or do so internal and switch automatically. Therefore enumerated standards also contain sets of one or more standard bits.
Assume a hypothetic tuner capable of demodulating B/PAL, G/PAL and I/PAL signals. The first enumerated standard is a set of B and G/PAL, switched automatically depending on the selected radio frequency in UHF or VHF band. Enumeration gives a "PAL-B/G" or "PAL-I" choice. Similar a Composite input may collapse standards, enumerating "PAL-B/G/H/I", "NTSC-M" and "SECAM-D/K".[6]
To query and select the standard used by the current video
input or output applications call the VIDIOC_G_STD and
VIDIOC_S_STD ioctl, respectively. The received
standard can be sensed with the VIDIOC_QUERYSTD ioctl. Note parameter of all these ioctls is a pointer to a v4l2_std_id type (a standard set), not an index into the standard enumeration.[7] Drivers must implement all video standard ioctls
when the device has one or more video inputs or outputs.
Special rules apply to USB cameras where the notion of video standards makes little sense. More generally any capture device, output devices accordingly, which is
incapable of capturing fields or frames at the nominal rate of the video standard, or
where timestamps refer to the instant the field or frame was received by the driver, not the capture time, or
where sequence numbers refer to the frames received by the driver, not the captured frames.
std field of struct v4l2_input and struct v4l2_output
to zero, the VIDIOC_G_STD,
VIDIOC_S_STD,
VIDIOC_QUERYSTD and
VIDIOC_ENUMSTD ioctls shall return the
EINVAL error code.[8]Example 1-5. Information about the current video standard
v4l2_std_id std_id; struct v4l2_standard standard; if (-1 == ioctl (fd,VIDIOC_G_STD, &std_id)) { /* Note when VIDIOC_ENUMSTD always returns EINVAL this is no video device or it falls under the USB exception, and VIDIOC_G_STD returning EINVAL is no error. */ perror ("VIDIOC_G_STD"); exit (EXIT_FAILURE); } memset (&standard, 0, sizeof (standard)); standard.index = 0; while (0 == ioctl (fd,VIDIOC_ENUMSTD, &standard)) { if (standard.id & std_id) { printf ("Current video standard: %s\n", standard.name); exit (EXIT_SUCCESS); } standard.index++; } /* EINVAL indicates the end of the enumeration, which cannot be empty unless this device falls under the USB exception. */ if (errno == EINVAL || standard.index == 0) { perror ("VIDIOC_ENUMSTD"); exit (EXIT_FAILURE); }
Example 1-6. Listing the video standards supported by the current input
struct v4l2_input input; struct v4l2_standard standard; memset (&input, 0, sizeof (input)); if (-1 == ioctl (fd,VIDIOC_G_INPUT, &input.index)) { perror ("VIDIOC_G_INPUT"); exit (EXIT_FAILURE); } if (-1 == ioctl (fd,VIDIOC_ENUMINPUT, &input)) { perror ("VIDIOC_ENUM_INPUT"); exit (EXIT_FAILURE); } printf ("Current input %s supports:\n", input.name); memset (&standard, 0, sizeof (standard)); standard.index = 0; while (0 == ioctl (fd,VIDIOC_ENUMSTD, &standard)) { if (standard.id & input.std) printf ("%s\n", standard.name); standard.index++; } /* EINVAL indicates the end of the enumeration, which cannot be empty unless this device falls under the USB exception. */ if (errno != EINVAL || standard.index == 0) { perror ("VIDIOC_ENUMSTD"); exit (EXIT_FAILURE); }
Example 1-7. Selecting a new video standard
struct v4l2_input input; v4l2_std_id std_id; memset (&input, 0, sizeof (input)); if (-1 == ioctl (fd,VIDIOC_G_INPUT, &input.index)) { perror ("VIDIOC_G_INPUT"); exit (EXIT_FAILURE); } if (-1 == ioctl (fd,VIDIOC_ENUMINPUT, &input)) { perror ("VIDIOC_ENUM_INPUT"); exit (EXIT_FAILURE); } if (0 == (input.std & V4L2_STD_PAL_BG)) { fprintf (stderr, "Oops. B/G PAL is not supported.\n"); exit (EXIT_FAILURE); } /* Note this is also supposed to work when only B or G/PAL is supported. */ std_id = V4L2_STD_PAL_BG; if (-1 == ioctl (fd,VIDIOC_S_STD, &std_id)) { perror ("VIDIOC_S_STD"); exit (EXIT_FAILURE); }
Devices typically have a number of user-settable controls such as brightness, saturation and so on, which would be presented to the user on a graphical user interface. But, different devices will have different controls available, and furthermore, the range of possible values, and the default value will vary from device to device. The control ioctls provide the information and a mechanism to create a nice user interface for these controls that will work correctly with any device.
All controls are accessed using an ID value. V4L2 defines
several IDs for specific purposes. Drivers can also implement their
own custom controls using V4L2_CID_PRIVATE_BASE
and higher values. The pre-defined control IDs have the prefix
V4L2_CID_, and are listed in Table 1-1. The ID is used when querying the attributes of
a control, and when getting or setting the current value.
Generally applications should present controls to the user without assumptions about their purpose. Each control comes with a name string the user is supposed to understand. When the purpose is non-intuitive the driver writer should provide a user manual, a user interface plug-in or a driver specific panel application. Predefined IDs were introduced to change a few controls programmatically, for example to mute a device during a channel switch.
Drivers may enumerate different controls after switching the current video input or output, tuner or modulator, or audio input or output. Different in the sense of other bounds, another default and current value, step size or other menu items. A control with a certain custom ID can also change name and type.[9] Control values are stored globally, they do not change when switching except to stay within the reported bounds. They also do not change e. g. when the device is opened or closed, when the tuner radio frequency is changed or generally never without application request. Since V4L2 specifies no event mechanism, panel applications intended to cooperate with other panel applications (be they built into a larger application, as a TV viewer) may need to regularly poll control values to update their user interface.[10]
Table 1-1. Control IDs
| ID | Type | Description |
|---|---|---|
V4L2_CID_BASE | First predefined ID, equal to
V4L2_CID_BRIGHTNESS. | |
V4L2_CID_USER_BASE | Synonym of V4L2_CID_BASE. | |
V4L2_CID_BRIGHTNESS | integer | Picture brightness, or more precisely, the black level. |
V4L2_CID_CONTRAST | integer | Picture contrast or luma gain. |
V4L2_CID_SATURATION | integer | Picture color saturation or chroma gain. |
V4L2_CID_HUE | integer | Hue or color balance. |
V4L2_CID_AUDIO_VOLUME | integer | Overall audio volume. Note some drivers also provide an OSS or ALSA mixer interface. |
V4L2_CID_AUDIO_BALANCE | integer | Audio stereo balance. Minimum corresponds to all the way left, maximum to right. |
V4L2_CID_AUDIO_BASS | integer | Audio bass adjustment. |
V4L2_CID_AUDIO_TREBLE | integer | Audio treble adjustment. |
V4L2_CID_AUDIO_MUTE | boolean | Mute audio, i. e. set the volume to zero, however
without affecting V4L2_CID_AUDIO_VOLUME. Like
ALSA drivers, V4L2 drivers must mute at load time to avoid excessive
noise. Actually the entire device should be reset to a low power
consumption state. |
V4L2_CID_AUDIO_LOUDNESS | boolean | Loudness mode (bass boost). |
V4L2_CID_BLACK_LEVEL | integer | Another name for brightness (not a synonym of
V4L2_CID_BRIGHTNESS). [?] |
V4L2_CID_AUTO_WHITE_BALANCE | boolean | Automatic white balance (cameras). |
V4L2_CID_DO_WHITE_BALANCE | button | This is an action control. When set (the value is
ignored), the device will do a white balance and then hold the current
setting. Contrast this with the boolean
V4L2_CID_AUTO_WHITE_BALANCE, which, when
activated, keeps adjusting the white balance. |
V4L2_CID_RED_BALANCE | integer | Red chroma balance. |
V4L2_CID_BLUE_BALANCE | integer | Blue chroma balance. |
V4L2_CID_GAMMA | integer | Gamma adjust. |
V4L2_CID_WHITENESS | integer | Whiteness for grey-scale devices. This is a synonym
for V4L2_CID_GAMMA. |
V4L2_CID_EXPOSURE | integer | Exposure (cameras). [Unit?] |
V4L2_CID_AUTOGAIN | boolean | Automatic gain/exposure control. |
V4L2_CID_GAIN | integer | Gain control. |
V4L2_CID_HFLIP | boolean | Mirror the picture horizontally. |
V4L2_CID_VFLIP | boolean | Mirror the picture vertically. |
V4L2_CID_HCENTER | integer | Horizontal image centering. |
V4L2_CID_VCENTER | integer | Vertical image centering. Centering is intended to physically adjust cameras. For image cropping see Section 1.11, for clipping Section 4.2. |
V4L2_CID_LASTP1 | End of the predefined control IDs
(currently V4L2_CID_VCENTER + 1). | |
V4L2_CID_PRIVATE_BASE | ID of the first custom (driver specific) control. Applications depending on particular custom controls should check the driver name and version, see Section 1.2. |
Applications can enumerate the available controls with the
VIDIOC_QUERYCTRL and VIDIOC_QUERYMENU ioctls, get and set a
control value with the VIDIOC_G_CTRL and VIDIOC_S_CTRL ioctls.
Drivers must implement VIDIOC_QUERYCTRL,
VIDIOC_G_CTRL and
VIDIOC_S_CTRL when the device has one or more
controls, VIDIOC_QUERYMENU when it has one or
more menu type controls.
Example 1-8. Enumerating all controls
struct v4l2_queryctrl queryctrl; struct v4l2_querymenu querymenu; static void enumerate_menu (void) { printf (" Menu items:\n"); memset (&querymenu, 0, sizeof (querymenu)); querymenu.id = queryctrl.id; for (querymenu.index = queryctrl.minimum; querymenu.index <= queryctrl.maximum; querymenu.index++) { if (0 == ioctl (fd,VIDIOC_QUERYMENU, &querymenu)) { printf (" %s\n", querymenu.name); } else { perror ("VIDIOC_QUERYMENU"); exit (EXIT_FAILURE); } } } memset (&queryctrl, 0, sizeof (queryctrl)); for (queryctrl.id = V4L2_CID_BASE; queryctrl.id < V4L2_CID_LASTP1; queryctrl.id++) { if (0 == ioctl (fd,VIDIOC_QUERYCTRL, &queryctrl)) { if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) continue; printf ("Control %s\n", queryctrl.name); if (queryctrl.type == V4L2_CTRL_TYPE_MENU) enumerate_menu (); } else { if (errno == EINVAL) continue; perror ("VIDIOC_QUERYCTRL"); exit (EXIT_FAILURE); } } for (queryctrl.id = V4L2_CID_PRIVATE_BASE;; queryctrl.id++) { if (0 == ioctl (fd,VIDIOC_QUERYCTRL, &queryctrl)) { if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) continue; printf ("Control %s\n", queryctrl.name); if (queryctrl.type == V4L2_CTRL_TYPE_MENU) enumerate_menu (); } else { if (errno == EINVAL) break; perror ("VIDIOC_QUERYCTRL"); exit (EXIT_FAILURE); } }
Example 1-9. Changing controls
struct v4l2_queryctrl queryctrl; struct v4l2_control control; memset (&queryctrl, 0, sizeof (queryctrl)); queryctrl.id = V4L2_CID_BRIGHTNESS; if (-1 == ioctl (fd,VIDIOC_QUERYCTRL, &queryctrl)) { if (errno != EINVAL) { perror ("VIDIOC_QUERYCTRL"); exit (EXIT_FAILURE); } else { printf ("V4L2_CID_BRIGHTNESS is not supported\n"); } } else if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) { printf ("V4L2_CID_BRIGHTNESS is not supported\n"); } else { memset (&control, 0, sizeof (control)); control.id = V4L2_CID_BRIGHTNESS; control.value = queryctrl.default_value; if (-1 == ioctl (fd,VIDIOC_S_CTRL, &control)) { perror ("VIDIOC_S_CTRL"); exit (EXIT_FAILURE); } } memset (&control, 0, sizeof (control)); control.id = V4L2_CID_CONTRAST; if (0 == ioctl (fd,VIDIOC_G_CTRL, &control)) { control.value += 1; /* The driver may clamp the value or return ERANGE, ignored here */ if (-1 == ioctl (fd,VIDIOC_S_CTRL, &control) && errno != ERANGE) { perror ("VIDIOC_S_CTRL"); exit (EXIT_FAILURE); } /* Ignore if V4L2_CID_CONTRAST is unsupported */ } else if (errno != EINVAL) { perror ("VIDIOC_G_CTRL"); exit (EXIT_FAILURE); } control.id = V4L2_CID_AUDIO_MUTE; control.value = TRUE; /* silence */ /* Errors ignored */ ioctl (fd, VIDIOC_S_CTRL, &control);
The control mechanism as originally designed was meant to be used for user settings (brightness, saturation, etc). However, it turned out to be a very useful model for implementing more complicated driver APIs where each driver implements only a subset of a larger API.
The MPEG encoding API was the driving force behind designing and implementing this extended control mechanism: the MPEG standard is quite large and the currently supported hardware MPEG encoders each only implement a subset of this standard. Further more, many parameters relating to how the video is encoded into an MPEG stream are specific to the MPEG encoding chip since the MPEG standard only defines the format of the resulting MPEG stream, not how the video is actually encoded into that format.
Unfortunately, the original control API lacked some features needed for these new uses and so it was extended into the (not terribly originally named) extended control API.
Three new ioctls are available: VIDIOC_G_EXT_CTRLS,
VIDIOC_S_EXT_CTRLS and VIDIOC_TRY_EXT_CTRLS. These ioctls act on
arrays of controls (as opposed to the VIDIOC_G_CTRL and
VIDIOC_S_CTRL ioctls that act on a single control). This is needed
since it is often required to set several controls simulatenously
(atomically).
Each of the new ioctls expects a pointer to a
struct v4l2_ext_controls. This structure contains a pointer to the control
array, a count of the number of controls in that array and a control
class. Control classes are used to group similar controls into a
single class. For example, control class
V4L2_CTRL_CLASS_USER contains all user controls
(i. e. all controls that can also be set using the old
VIDIOC_S_CTRL ioctl). Control class
V4L2_CTRL_CLASS_MPEG contains all controls
relating to MPEG encoding, etc.
All controls in the control array must belong to the specified control class. An error is returned if this is not the case.
It is also possible to use an empty control array (count == 0) to check whether the specified control class is supported.
The control array is a struct v4l2_ext_control array. The
v4l2_ext_control structure is very similar to
struct v4l2_control, except for the fact that it also allows for 64-bit
values and pointers to be passed (although the latter is not yet used
anywhere).
It is important to realize that due to the flexibility of
controls it is necessary to check whether the control you want to set
actually is supported in the driver and what the valid range of values
is. So use the VIDIOC_QUERYCTRL and VIDIOC_QUERYMENU ioctls to
check this. Also note that it is possible that some of the menu
indices in a control of type V4L2_CTRL_TYPE_MENU
may not be supported (VIDIOC_QUERYMENU will
return an error). A good example is the list of supported MPEG audio
bitrates. Some drivers only support one or two bitrates, others
support a wider range.
The recommended way to enumerate over the extended
controls is by using VIDIOC_QUERYCTRL in combination with the
V4L2_CTRL_FLAG_NEXT_CTRL flag:
struct v4l2_queryctrl qctrl;
qctrl.id = V4L2_CTRL_FLAG_NEXT_CTRL;
while (0 == ioctl (fd, VIDIOC_QUERYCTRL, &qctrl)) {
/* ... */
qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL;
}The initial control ID is set to 0 ORed with the
V4L2_CTRL_FLAG_NEXT_CTRL flag. The
VIDIOC_QUERYCTRL ioctl will return the first
control with a higher ID than the specified one. When no such controls
are found an error is returned.
If you want to get all controls within a specific control
class, then you can set the initial
qctrl.id value to the control class and add
an extra check to break out of the loop when a control of another
control class is found:
qctrl.id = V4L2_CTRL_CLASS_MPEG | V4L2_CTRL_FLAG_NEXT_CTRL;
while (0 == ioctl (fd, VIDIOC_QUERYCTRL, &qctrl)) {
if (V4L2_CTRL_ID2CLASS (qctrl.id) != V4L2_CTRL_CLASS_MPEG)
break;
/* ... */
qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL;
}The 32-bit qctrl.id value is
subdivided into three bit ranges: the top 4 bits are reserved for
flags (e. g. V4L2_CTRL_FLAG_NEXT_CTRL) and are not
actually part of the ID. The remaining 28 bits form the control ID, of
which the most significant 12 bits define the control class and the
least significant 16 bits identify the control within the control
class. It is guaranteed that these last 16 bits are always non-zero
for controls. The range of 0x1000 and up are reserved for
driver-specific controls. The macro
V4L2_CTRL_ID2CLASS(id) returns the control class
ID based on a control ID.
If the driver does not support extended controls, then
VIDIOC_QUERYCTRL will fail when used in
combination with V4L2_CTRL_FLAG_NEXT_CTRL. In
that case the old method of enumerating control should be used (see
1.8). But if it is supported, then it is guaranteed to enumerate over
all controls, including driver-private controls.
It is possible to create control panels for a graphical
user interface where the user can select the various controls.
Basically you will have to iterate over all controls using the method
described above. Each control class starts with a control of type
V4L2_CTRL_TYPE_CTRL_CLASS.
VIDIOC_QUERYCTRL will return the name of this
control class which can be used as the title of a tab page within a
control panel.
The flags field of struct v4l2_queryctrl also contains hints on
the behavior of the control. See the VIDIOC_QUERYCTRL documentation
for more details.
Below all controls within the MPEG control class are described. First the generic controls, then controls specific for certain hardware.
Table 1-2. MPEG Control IDs
| ID | Type | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_CLASS | class | ||||||||||||||||||||||||||||||
The MPEG class
descriptor. Calling VIDIOC_QUERYCTRL for this control will return a
description of this control class. This description can be used as the
caption of a Tab page in a GUI, for example. | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_STREAM_TYPE | enum | ||||||||||||||||||||||||||||||
| The MPEG-1, -2 or -4 output stream type. One cannot assume anything here. Each hardware MPEG encoder tends to support different subsets of the available MPEG stream types. The currently defined stream types are: | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_STREAM_PID_PMT | integer | ||||||||||||||||||||||||||||||
| Program Map Table Packet ID for the MPEG transport stream (default 16) | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_STREAM_PID_AUDIO | integer | ||||||||||||||||||||||||||||||
| Audio Packet ID for the MPEG transport stream (default 256) | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_STREAM_PID_VIDEO | integer | ||||||||||||||||||||||||||||||
| Video Packet ID for the MPEG transport stream (default 260) | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_STREAM_PID_PCR | integer | ||||||||||||||||||||||||||||||
| Packet ID for the MPEG transport stream carrying PCR fields (default 259) | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_STREAM_PES_ID_AUDIO | integer | ||||||||||||||||||||||||||||||
| Audio ID for MPEG PES | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_STREAM_PES_ID_VIDEO | integer | ||||||||||||||||||||||||||||||
| Video ID for MPEG PES | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_STREAM_VBI_FMT | enum | ||||||||||||||||||||||||||||||
| Some cards can embed VBI data (e. g. Closed Caption, Teletext) into the MPEG stream. This control selects whether VBI data should be embedded, and if so, what embedding method should be used. The list of possible VBI formats depends on the driver. The currently defined VBI format types are: | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ | enum | ||||||||||||||||||||||||||||||
| MPEG Audio sampling frequency. Possible values are: | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_AUDIO_ENCODING | enum | ||||||||||||||||||||||||||||||
| MPEG Audio encoding. Possible values are: | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_AUDIO_L1_BITRATE | enum | ||||||||||||||||||||||||||||||
| Layer I bitrate. Possible values are: | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_AUDIO_L2_BITRATE | enum | ||||||||||||||||||||||||||||||
| Layer II bitrate. Possible values are: | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_AUDIO_L3_BITRATE | enum | ||||||||||||||||||||||||||||||
| Layer III bitrate. Possible values are: | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_AUDIO_MODE | enum | ||||||||||||||||||||||||||||||
| MPEG Audio mode. Possible values are: | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_AUDIO_MODE_EXTENSION | enum | ||||||||||||||||||||||||||||||
| Joint Stereo audio mode extension. In Layer I and II they indicate which subbands are in intensity stereo. All other subbands are coded in stereo. Layer III is not (yet) supported. Possible values are: | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_AUDIO_EMPHASIS | enum | ||||||||||||||||||||||||||||||
| Audio Emphasis. Possible values are: | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_AUDIO_CRC | enum | ||||||||||||||||||||||||||||||
| CRC method. Possible values are: | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_AUDIO_MUTE | bool | ||||||||||||||||||||||||||||||
| Mutes the audio when capturing. This is not done by muting audio hardware, which can still produce a slight hiss, but in the encoder itself, guaranteeing a fixed and reproducable audio bitstream. 0 = unmuted, 1 = muted. | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_VIDEO_ENCODING | enum | ||||||||||||||||||||||||||||||
| MPEG Video encoding method. Possible values are: | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_VIDEO_ASPECT | enum | ||||||||||||||||||||||||||||||
| Video aspect. Possible values are: | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_VIDEO_B_FRAMES | integer | ||||||||||||||||||||||||||||||
| Number of B-Frames (default 2) | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_VIDEO_GOP_SIZE | integer | ||||||||||||||||||||||||||||||
| GOP size (default 12) | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_VIDEO_GOP_CLOSURE | bool | ||||||||||||||||||||||||||||||
| GOP closure (default 1) | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_VIDEO_PULLDOWN | bool | ||||||||||||||||||||||||||||||
| Enable 3:2 pulldown (default 0) | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_VIDEO_BITRATE_MODE | enum | ||||||||||||||||||||||||||||||
| Video bitrate mode. Possible values are: | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_VIDEO_BITRATE | integer | ||||||||||||||||||||||||||||||
| Video bitrate in bits per second. | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_VIDEO_BITRATE_PEAK | integer | ||||||||||||||||||||||||||||||
| Peak video bitrate in bits per second. Must be larger or equal to the average video bitrate. It is ignored if the video bitrate mode is set to constant bitrate. | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_VIDEO_TEMPORAL_DECIMATION | integer | ||||||||||||||||||||||||||||||
| For every captured frame, skip this many subsequent frames (default 0). | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_VIDEO_MUTE | bool | ||||||||||||||||||||||||||||||
| "Mutes" the video to a fixed color when capturing. This is useful for testing, to produce a fixed video bitstream. 0 = unmuted, 1 = muted. | |||||||||||||||||||||||||||||||
V4L2_CID_MPEG_VIDEO_MUTE_YUV | integer | ||||||||||||||||||||||||||||||
| Sets the "mute" color of the video. The supplied 32-bit integer is interpreted as follows (bit 0 = least significant bit): | |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
The following MPEG class controls deal with MPEG encoding settings that are specific to the Conexant CX23415 and CX23416 MPEG encoding chips.
Table 1-3. CX2341x Control IDs
| ID | Type | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | |||||||||||||
V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE | enum | ||||||||||||
Sets the Spatial
Filter mode (default MANUAL). Possible values
are: | |||||||||||||
| |||||||||||||
V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER | integer (0-15) | ||||||||||||
| The setting for the Spatial Filter. 0 = off, 15 = maximum. (Default is 0.) | |||||||||||||
V4L2_CID_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE | enum | ||||||||||||
Select the algorithm
to use for the Luma Spatial Filter (default
1D_HOR). Possible values: | |||||||||||||
| |||||||||||||
V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_SPATIAL_FILTER_TYPE | enum | ||||||||||||
Select the algorithm
for the Chroma Spatial Filter (default 1D_HOR).
Possible values are: | |||||||||||||
| |||||||||||||
V4L2_CID_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER_MODE | enum | ||||||||||||
Sets the Temporal
Filter mode (default MANUAL). Possible values
are: | |||||||||||||