Video for Linux Two API Specification

Revision 0.24

Michael H Schimek

            
          

Bill Dirks

Hans Verkuil

Martin Rubli

This document is copyrighted © 1999-2008 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.


Table of Contents
Introduction
1. Common API Elements
1.1. Opening and Closing Devices
1.1.1. Device Naming
1.1.2. Related Devices
1.1.3. Multiple Opens
1.1.4. Shared Data Streams
1.1.5. Functions
1.2. Querying Capabilities
1.3. Application Priority
1.4. Video Inputs and Outputs
1.5. Audio Inputs and Outputs
1.6. Tuners and Modulators
1.6.1. Tuners
1.6.2. Modulators
1.6.3. Radio Frequency
1.6.4. Satellite Receivers
1.7. Video Standards
1.8. User Controls
1.9. Extended Controls
1.9.1. Introduction
1.9.2. The Extended Control API
1.9.3. Enumerating Extended Controls
1.9.4. Creating Control Panels
1.9.5. MPEG Control Reference
1.9.6. Camera Control Reference
1.10. Data Formats
1.10.1. Data Format Negotiation
1.10.2. Image Format Enumeration
1.11. Image Cropping, Insertion and Scaling
1.11.1. Cropping Structures
1.11.2. Scaling Adjustments
1.11.3. Examples
1.12. Streaming Parameters
2. Image Formats
2.1. Standard Image Formats
2.2. Colorspaces
2.3. Indexed Format
2.4. RGB Formats
Packed RGB formats -- Packed RGB formats
V4L2_PIX_FMT_SBGGR8 ('BA81') -- Bayer RGB format
V4L2_PIX_FMT_SBGGR16 ('BA82') -- Bayer RGB format
2.5. YUV Formats
Packed YUV formats -- Packed YUV formats
V4L2_PIX_FMT_GREY ('GREY') -- Grey-scale image
V4L2_PIX_FMT_Y16 ('Y16 ') -- Grey-scale image
V4L2_PIX_FMT_YUYV ('YUYV') -- Packed format with ½ horizontal chroma resolution, also known as YUV 4:2:2
V4L2_PIX_FMT_UYVY ('UYVY') -- Variation of V4L2_PIX_FMT_YUYV with different order of samples in memory
V4L2_PIX_FMT_Y41P ('Y41P') -- Format with ¼ horizontal chroma resolution, also known as YUV 4:1:1
V4L2_PIX_FMT_YVU420 ('YV12'), V4L2_PIX_FMT_YUV420 ('YU12') -- Planar formats with ½ horizontal and vertical chroma resolution, also known as YUV 4:2:0
V4L2_PIX_FMT_YVU410 ('YVU9'), V4L2_PIX_FMT_YUV410 ('YUV9') -- Planar formats with ¼ horizontal and vertical chroma resolution, also known as YUV 4:1:0
V4L2_PIX_FMT_YUV422P ('422P') -- Format with ½ horizontal chroma resolution, also known as YUV 4:2:2. Planar layout as opposed to V4L2_PIX_FMT_YUYV
V4L2_PIX_FMT_YUV411P ('411P') -- Format with ¼ horizontal chroma resolution, also known as YUV 4:1:1. Planar layout as opposed to V4L2_PIX_FMT_Y41P
V4L2_PIX_FMT_NV12 ('NV12'), V4L2_PIX_FMT_NV21 ('NV21') -- Formats with ½ horizontal and vertical chroma resolution, also known as YUV 4:2:0. One luminance and one chrominance plane with alternating chroma samples as opposed to V4L2_PIX_FMT_YVU420
2.6. Compressed Formats
2.7. Reserved Format Identifiers
3. Input/Output
3.1. Read/Write
3.2. Streaming I/O (Memory Mapping)
3.3. Streaming I/O (User Pointers)
3.4. Asynchronous I/O
3.5. Buffers
3.5.1. Timecodes
3.6. Field Order
4. Interfaces
4.1. Video Capture Interface
4.1.1. Querying Capabilities
4.1.2. Supplemental Functions
4.1.3. Image Format Negotiation
4.1.4. Reading Images
4.2. Video Overlay Interface
4.2.1. Querying Capabilities
4.2.2. Supplemental Functions
4.2.3. Setup
4.2.4. Overlay Window
4.2.5. Enabling Overlay
4.3. Video Output Interface
4.3.1. Querying Capabilities
4.3.2. Supplemental Functions
4.3.3. Image Format Negotiation
4.3.4. Writing Images
4.4. Video Output Overlay Interface
4.4.1. Querying Capabilities
4.4.2. Framebuffer
4.4.3. Overlay Window and Scaling
4.4.4. Enabling Overlay
4.5. Codec Interface
4.6. Effect Devices Interface
4.7. Raw VBI Data Interface
4.7.1. Querying Capabilities
4.7.2. Supplemental Functions
4.7.3. Raw VBI Format Negotiation
4.7.4. Reading and writing VBI images
4.8. Sliced VBI Data Interface
4.8.1. Querying Capabilities
4.8.2. Supplemental Functions
4.8.3. Sliced VBI Format Negotiation
4.8.4. Reading and writing sliced VBI data
4.9. Teletext Interface
4.10. Radio Interface
4.10.1. Querying Capabilities
4.10.2. Supplemental Functions
4.10.3. Programming
4.11. RDS Interface
I. Function Reference
V4L2 close() -- Close a V4L2 device
V4L2 ioctl() -- Program a V4L2 device
ioctl VIDIOC_CROPCAP -- Information about the video cropping and scaling abilities
ioctl VIDIOC_DBG_G_REGISTER, VIDIOC_DBG_S_REGISTER -- Read or write hardware registers
ioctl VIDIOC_ENCODER_CMD, VIDIOC_TRY_ENCODER_CMD -- Execute an encoder command
ioctl VIDIOC_ENUMAUDIO -- Enumerate audio inputs
ioctl VIDIOC_ENUMAUDOUT -- Enumerate audio outputs
ioctl VIDIOC_ENUM_FMT -- Enumerate image formats
ioctl VIDIOC_ENUM_FRAMESIZES -- Enumerate frame sizes
ioctl VIDIOC_ENUM_FRAMEINTERVALS -- Enumerate frame intervals
ioctl VIDIOC_ENUMINPUT -- Enumerate video inputs
ioctl VIDIOC_ENUMOUTPUT -- Enumerate video outputs
ioctl VIDIOC_ENUMSTD -- Enumerate supported video standards
ioctl VIDIOC_G_AUDIO, VIDIOC_S_AUDIO -- Query or select the current audio input and its attributes
ioctl VIDIOC_G_AUDOUT, VIDIOC_S_AUDOUT -- Query or select the current audio output
ioctl VIDIOC_G_CHIP_IDENT -- Identify the chips on a TV card
ioctl VIDIOC_G_CROP, VIDIOC_S_CROP -- Get or set the current cropping rectangle
ioctl VIDIOC_G_CTRL, VIDIOC_S_CTRL -- Get or set the value of a control
ioctl VIDIOC_G_ENC_INDEX -- Get meta data about a compressed video stream
ioctl VIDIOC_G_EXT_CTRLS, VIDIOC_S_EXT_CTRLS, VIDIOC_TRY_EXT_CTRLS -- Get or set the value of several controls, try control values
ioctl VIDIOC_G_FBUF, VIDIOC_S_FBUF -- Get or set frame buffer overlay parameters
ioctl VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_TRY_FMT -- Get or set the data format, try a format
ioctl VIDIOC_G_FREQUENCY, VIDIOC_S_FREQUENCY -- Get or set tuner or modulator radio frequency
ioctl VIDIOC_G_INPUT, VIDIOC_S_INPUT -- Query or select the current video input
ioctl VIDIOC_G_JPEGCOMP, VIDIOC_S_JPEGCOMP -- 
ioctl VIDIOC_G_MODULATOR, VIDIOC_S_MODULATOR -- Get or set modulator attributes
ioctl VIDIOC_G_OUTPUT, VIDIOC_S_OUTPUT -- Query or select the current video output
ioctl VIDIOC_G_PARM, VIDIOC_S_PARM -- Get or set streaming parameters
ioctl VIDIOC_G_PRIORITY, VIDIOC_S_PRIORITY -- Query or request the access priority associated with a file descriptor
ioctl VIDIOC_G_SLICED_VBI_CAP -- Query sliced VBI capabilities
ioctl VIDIOC_G_STD, VIDIOC_S_STD -- Query or select the video standard of the current input
ioctl VIDIOC_G_TUNER, VIDIOC_S_TUNER -- Get or set tuner attributes
ioctl VIDIOC_LOG_STATUS -- Log driver status information
ioctl VIDIOC_OVERLAY -- Start or stop video overlay
ioctl VIDIOC_QBUF, VIDIOC_DQBUF -- Exchange a buffer with the driver
ioctl VIDIOC_QUERYBUF -- Query the status of a buffer
ioctl VIDIOC_QUERYCAP -- Query device capabilities
ioctl VIDIOC_QUERYCTRL, VIDIOC_QUERYMENU -- Enumerate controls and menu control items
ioctl VIDIOC_QUERYSTD -- Sense the video standard received by the current input
ioctl VIDIOC_REQBUFS -- Initiate Memory Mapping or User Pointer I/O
ioctl VIDIOC_STREAMON, VIDIOC_STREAMOFF -- Start or stop streaming I/O
V4L2 mmap() -- Map device memory into application address space
V4L2 munmap() -- Unmap device memory
V4L2 open() -- Open a V4L2 device
V4L2 poll() -- Wait for some event on a file descriptor
V4L2 read() -- Read from a V4L2 device
V4L2 select() -- Synchronous I/O multiplexing
V4L2 write() -- Write to a V4L2 device
5. V4L2 Driver Programming
6. Changes
6.1. Differences between V4L and V4L2
6.1.1. Opening and Closing Devices
6.1.2. Querying Capabilities
6.1.3. Video Sources
6.1.4. Tuning
6.1.5. Image Properties
6.1.6. Audio
6.1.7. Frame Buffer Overlay
6.1.8. Cropping
6.1.9. Reading Images, Memory Mapping
6.1.10. Reading Raw VBI Data
6.1.11. Miscellaneous
6.2. Changes of the V4L2 API
6.2.1. Early Versions
6.2.2. V4L2 Version 0.16 1999-01-31
6.2.3. V4L2 Version 0.18 1999-03-16
6.2.4. V4L2 Version 0.19 1999-06-05
6.2.5. V4L2 Version 0.20 (1999-09-10)
6.2.6. V4L2 Version 0.20 incremental changes
6.2.7. V4L2 Version 0.20 2000-11-23
6.2.8. V4L2 Version 0.20 2002-07-25
6.2.9. V4L2 in Linux 2.5.46, 2002-10
6.2.10. V4L2 2003-06-19
6.2.11. V4L2 2003-11-05
6.2.12. V4L2 in Linux 2.6.6, 2004-05-09
6.2.13. V4L2 in Linux 2.6.8
6.2.14. V4L2 spec erratum 2004-08-01
6.2.15. V4L2 in Linux 2.6.14
6.2.16. V4L2 in Linux 2.6.15
6.2.17. V4L2 spec erratum 2005-11-27
6.2.18. V4L2 spec erratum 2006-01-10
6.2.19. V4L2 spec erratum 2006-02-03
6.2.20. V4L2 spec erratum 2006-02-04
6.2.21. V4L2 in Linux 2.6.17
6.2.22. V4L2 spec erratum 2006-09-23 (Draft 0.15)
6.2.23. V4L2 in Linux 2.6.18
6.2.24. V4L2 in Linux 2.6.19
6.2.25. V4L2 spec erratum 2006-10-12 (Draft 0.17)
6.2.26. V4L2 in Linux 2.6.21
6.2.27. V4L2 in Linux 2.6.22
6.2.28. V4L2 in Linux 2.6.24
6.2.29. V4L2 in Linux 2.6.25
6.3. Relation of V4L2 to other Linux multimedia APIs
6.3.1. X Video Extension
6.3.2. Digital Video
6.3.3. Audio Interfaces
6.4. Experimental API Elements
6.5. Obsolete API Elements
A. Video For Linux Two Header File
B. Video Capture Example
C. GNU Free Documentation License
C.1. 0. PREAMBLE
C.2. 1. APPLICABILITY AND DEFINITIONS
C.3. 2. VERBATIM COPYING
C.4. 3. COPYING IN QUANTITY
C.5. 4. MODIFICATIONS
C.6. 5. COMBINING DOCUMENTS
C.7. 6. COLLECTIONS OF DOCUMENTS
C.8. 7. AGGREGATION WITH INDEPENDENT WORKS
C.9. 8. TRANSLATION
C.10. 9. TERMINATION
C.11. 10. FUTURE REVISIONS OF THIS LICENSE
C.12. Addendum
List of Types
References
List of Figures
1-1. Image Cropping, Insertion and Scaling
3-1. Field Order, Top Field First Transmitted
3-2. Field Order, Bottom Field First Transmitted
4-1. Line synchronization
4-2. ITU-R 525 line numbering (M/NTSC and M/PAL)
4-3. ITU-R 625 line numbering
List of Examples
1-1. Information about the current video input
1-2. Switching to the first video input
1-3. Information about the current audio input
1-4. Switching to the first audio input
1-5. Information about the current video standard
1-6. Listing the video standards supported by the current input
1-7. Selecting a new video standard
1-8. Enumerating all controls
1-9. Changing controls
1-10. Resetting the cropping parameters
1-11. Simple downscaling
1-12. Selecting an output area
1-13. Current scaling factor and pixel aspect
2-1. ITU-R Rec. BT.601 color conversion
2-1. V4L2_PIX_FMT_BGR24 4 × 4 pixel image
2-1. V4L2_PIX_FMT_SBGGR8 4 × 4 pixel image
2-1. V4L2_PIX_FMT_SBGGR16 4 × 4 pixel image
2-1. V4L2_PIX_FMT_GREY 4 × 4 pixel image
2-1. V4L2_PIX_FMT_Y16 4 × 4 pixel image
2-1. V4L2_PIX_FMT_YUYV 4 × 4 pixel image
2-1. V4L2_PIX_FMT_UYVY 4 × 4 pixel image
2-1. V4L2_PIX_FMT_Y41P 8 × 4 pixel image
2-1. V4L2_PIX_FMT_YVU420 4 × 4 pixel image
2-1. V4L2_PIX_FMT_YVU410 4 × 4 pixel image
2-1. V4L2_PIX_FMT_YUV422P 4 × 4 pixel image
2-1. V4L2_PIX_FMT_YUV411P 4 × 4 pixel image
2-1. V4L2_PIX_FMT_NV12 4 × 4 pixel image
3-1. Mapping buffers
3-2. Initiating streaming I/O with user pointers
4-1. Finding a framebuffer device for OSD

Introduction

Video 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.


Chapter 1. Common API Elements

Programming a V4L2 device consists of these steps:

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.


1.1. Opening and Closing Devices

1.1.1. Device Naming

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:

> insmod mydriver.o video_nr=0,1 radio_nr=0,1

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 mydriver              (1)
options mydriver video_nr=0,1 radio_nr=0,1   (2)
          
(1)
When an application attempts to open a device special file with major number 81 and minor number 0, 1, or 64, load "mydriver" (and the "videodev" module it depends upon).
(2)
Register the first two video capture devices with minor number 0 and 1 (base number is 0), the first two radio device with minor number 64 and 65 (base 64).

When no minor number is given as module option the driver supplies a default. Chapter 4 recommends the base minor numbers to be used for the various device types. Obviously minor numbers must be unique. When the number is already in use the offending device will not be registered.

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.


1.1.2. Related Devices

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.


1.1.3. Multiple Opens

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.


1.1.4. Shared Data Streams

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.


1.1.5. Functions

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.


1.2. Querying Capabilities

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.


1.3. Application Priority

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.


1.4. Video Inputs and Outputs

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);
}
      

1.5. Audio Inputs and Outputs

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);
}
      

1.6. Tuners and Modulators

1.6.1. Tuners

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.


1.6.2. Modulators

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.


1.6.3. Radio Frequency

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.


1.6.4. Satellite Receivers

To be discussed. See also proposals by Peter Schlaf, video4linux-list@redhat.com on 23 Oct 2002, subject: "Re: [V4L] Re: v4l2 api".


1.7. Video Standards

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.

Here the driver shall set the 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);
}
      

1.8. User Controls

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

IDTypeDescription
V4L2_CID_BASE First predefined ID, equal to V4L2_CID_BRIGHTNESS.
V4L2_CID_USER_BASE Synonym of V4L2_CID_BASE.
V4L2_CID_BRIGHTNESSintegerPicture brightness, or more precisely, the black level.
V4L2_CID_CONTRASTintegerPicture contrast or luma gain.
V4L2_CID_SATURATIONintegerPicture color saturation or chroma gain.
V4L2_CID_HUEintegerHue or color balance.
V4L2_CID_AUDIO_VOLUMEintegerOverall audio volume. Note some drivers also provide an OSS or ALSA mixer interface.
V4L2_CID_AUDIO_BALANCEintegerAudio stereo balance. Minimum corresponds to all the way left, maximum to right.
V4L2_CID_AUDIO_BASSintegerAudio bass adjustment.
V4L2_CID_AUDIO_TREBLEintegerAudio treble adjustment.
V4L2_CID_AUDIO_MUTEbooleanMute 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_LOUDNESSbooleanLoudness mode (bass boost).
V4L2_CID_BLACK_LEVELintegerAnother name for brightness (not a synonym of V4L2_CID_BRIGHTNESS). This control is deprecated and should not be used in new drivers and applications.
V4L2_CID_AUTO_WHITE_BALANCEbooleanAutomatic white balance (cameras).
V4L2_CID_DO_WHITE_BALANCEbuttonThis 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_BALANCEintegerRed chroma balance.
V4L2_CID_BLUE_BALANCEintegerBlue chroma balance.
V4L2_CID_GAMMAintegerGamma adjust.
V4L2_CID_WHITENESSintegerWhiteness for grey-scale devices. This is a synonym for V4L2_CID_GAMMA. This control is deprecated and should not be used in new drivers and applications.
V4L2_CID_EXPOSUREintegerExposure (cameras). [Unit?]
V4L2_CID_AUTOGAINbooleanAutomatic gain/exposure control.
V4L2_CID_GAINintegerGain control.
V4L2_CID_HFLIPbooleanMirror the picture horizontally.
V4L2_CID_VFLIPbooleanMirror the picture vertically.
V4L2_CID_HCENTER_DEPRECATED (formerly V4L2_CID_HCENTER)integerHorizontal image centering. This control is deprecated. New drivers and applications should use the Camera class controls V4L2_CID_PAN_ABSOLUTE, V4L2_CID_PAN_RELATIVE and V4L2_CID_PAN_RESET instead.
V4L2_CID_VCENTER_DEPRECATED (formerly V4L2_CID_VCENTER)integerVertical image centering. Centering is intended to physically adjust cameras. For image cropping see Section 1.11, for clipping Section 4.2. This control is deprecated. New drivers and applications should use the Camera class controls V4L2_CID_TILT_ABSOLUTE, V4L2_CID_TILT_RELATIVE and V4L2_CID_TILT_RESET instead.
V4L2_CID_POWER_LINE_FREQUENCYintegerEnables a power line frequency filter to avoid flicker. Possible values are: V4L2_CID_POWER_LINE_FREQUENCY_DISABLED (0), V4L2_CID_POWER_LINE_FREQUENCY_50HZ (1) and V4L2_CID_POWER_LINE_FREQUENCY_60HZ (2).
V4L2_CID_HUE_AUTObooleanEnables automatic hue control by the device. The effect of setting V4L2_CID_HUE while automatic hue control is enabled is undefined, drivers should ignore such request.
V4L2_CID_WHITE_BALANCE_TEMPERATUREintegerThis control specifies the white balance settings as a color temperature in Kelvin. A driver should have a minimum of 2800 (incandescent) to 6500 (daylight). For more information about color temperature see Wikipedia.
V4L2_CID_SHARPNESSintegerAdjusts the sharpness filters in a camera. The minimum value disables the filters, higher values give a sharper picture.
V4L2_CID_BACKLIGHT_COMPENSATIONintegerAdjusts the backlight compensation in a camera. The minimum value disables backlight compensation.
V4L2_CID_LASTP1 End of the predefined control IDs (currently V4L2_CID_BACKLIGHT_COMPENSATION + 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);

1.9. Extended Controls

1.9.1. Introduction

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.


1.9.2. The 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 atomically change several controls at once.

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.


1.9.3. Enumerating Extended Controls

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.


1.9.4. Creating Control Panels

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.


1.9.5. MPEG Control Reference

Below all controls within the MPEG control class are described. First the generic controls, then controls specific for certain hardware.


1.9.5.1. Generic MPEG Controls

Table 1-2. MPEG Control IDs

IDType 
 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_MPEG_STREAM_TYPE_MPEG2_PS MPEG-2 program stream
V4L2_MPEG_STREAM_TYPE_MPEG2_TS MPEG-2 transport stream
V4L2_MPEG_STREAM_TYPE_MPEG1_SS MPEG-1 system stream
V4L2_MPEG_STREAM_TYPE_MPEG2_DVD MPEG-2 DVD-compatible stream
V4L2_MPEG_STREAM_TYPE_MPEG1_VCD MPEG-1 VCD-compatible stream
V4L2_MPEG_STREAM_TYPE_MPEG2_SVCD MPEG-2 SVCD-compatible stream
    
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_MPEG_STREAM_VBI_FMT_NONE No VBI in the MPEG stream
V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI in private packets, IVTV format (documented in the kernel sources in the file Documentation/video4linux/cx2341x/README.vbi)
    
V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ enum 
 MPEG Audio sampling frequency. Possible values are:
 
V4L2_MPEG_AUDIO_SAMPLING_FREQ_44100 44.1 kHz
V4L2_MPEG_AUDIO_SAMPLING_FREQ_48000 48 kHz
V4L2_MPEG_AUDIO_SAMPLING_FREQ_32000 32 kHz
    
V4L2_CID_MPEG_AUDIO_ENCODING enum 
 MPEG Audio encoding. Possible values are:
 
V4L2_MPEG_AUDIO_ENCODING_LAYER_1 MPEG Layer I encoding
V4L2_MPEG_AUDIO_ENCODING_LAYER_2 MPEG Layer II encoding
V4L2_MPEG_AUDIO_ENCODING_LAYER_3 MPEG Layer III encoding
    
V4L2_CID_MPEG_AUDIO_L1_BITRATE enum 
 Layer I bitrate. Possible values are:
 
V4L2_MPEG_AUDIO_L1_BITRATE_32K 32 kbit/s
V4L2_MPEG_AUDIO_L1_BITRATE_64K 64 kbit/s
V4L2_MPEG_AUDIO_L1_BITRATE_96K 96 kbit/s
V4L2_MPEG_AUDIO_L1_BITRATE_128K 128 kbit/s
V4L2_MPEG_AUDIO_L1_BITRATE_160K 160 kbit/s
V4L2_MPEG_AUDIO_L1_BITRATE_192K 192 kbit/s
V4L2_MPEG_AUDIO_L1_BITRATE_224K 224 kbit/s
V4L2_MPEG_AUDIO_L1_BITRATE_256K 256 kbit/s
V4L2_MPEG_AUDIO_L1_BITRATE_288K 288 kbit/s
V4L2_MPEG_AUDIO_L1_BITRATE_320K 320 kbit/s
V4L2_MPEG_AUDIO_L1_BITRATE_352K 352 kbit/s
V4L2_MPEG_AUDIO_L1_BITRATE_384K 384 kbit/s
V4L2_MPEG_AUDIO_L1_BITRATE_416K 416 kbit/s
V4L2_MPEG_AUDIO_L1_BITRATE_448K 448 kbit/s
    
V4L2_CID_MPEG_AUDIO_L2_BITRATE enum 
 Layer II bitrate. Possible values are:
 
V4L2_MPEG_AUDIO_L2_BITRATE_32K 32 kbit/s
V4L2_MPEG_AUDIO_L2_BITRATE_48K 48 kbit/s
V4L2_MPEG_AUDIO_L2_BITRATE_56K 56 kbit/s
V4L2_MPEG_AUDIO_L2_BITRATE_64K 64 kbit/s
V4L2_MPEG_AUDIO_L2_BITRATE_80K 80 kbit/s
V4L2_MPEG_AUDIO_L2_BITRATE_96K 96 kbit/s
V4L2_MPEG_AUDIO_L2_BITRATE_112K 112 kbit/s
V4L2_MPEG_AUDIO_L2_BITRATE_128K 128 kbit/s
V4L2_MPEG_AUDIO_L2_BITRATE_160K 160 kbit/s
V4L2_MPEG_AUDIO_L2_BITRATE_192K 192 kbit/s
V4L2_MPEG_AUDIO_L2_BITRATE_224K 224 kbit/s
V4L2_MPEG_AUDIO_L2_BITRATE_256K 256 kbit/s
V4L2_MPEG_AUDIO_L2_BITRATE_320K 320 kbit/s
V4L2_MPEG_AUDIO_L2_BITRATE_384K 384 kbit/s
    
V4L2_CID_MPEG_AUDIO_L3_BITRATE enum 
 Layer III bitrate. Possible values are:
 
V4L2_MPEG_AUDIO_L3_BITRATE_32K 32 kbit/s
V4L2_MPEG_AUDIO_L3_BITRATE_40K 40 kbit/s
V4L2_MPEG_AUDIO_L3_BITRATE_48K 48 kbit/s
V4L2_MPEG_AUDIO_L3_BITRATE_56K 56 kbit/s
V4L2_MPEG_AUDIO_L3_BITRATE_64K 64 kbit/s
V4L2_MPEG_AUDIO_L3_BITRATE_80K 80 kbit/s
V4L2_MPEG_AUDIO_L3_BITRATE_96K 96 kbit/s
V4L2_MPEG_AUDIO_L3_BITRATE_112K 112 kbit/s
V4L2_MPEG_AUDIO_L3_BITRATE_128K 128 kbit/s
V4L2_MPEG_AUDIO_L3_BITRATE_160K 160 kbit/s
V4L2_MPEG_AUDIO_L3_BITRATE_192K 192 kbit/s
V4L2_MPEG_AUDIO_L3_BITRATE_224K 224 kbit/s
V4L2_MPEG_AUDIO_L3_BITRATE_256K 256 kbit/s
V4L2_MPEG_AUDIO_L3_BITRATE_320K 320 kbit/s
    
V4L2_CID_MPEG_AUDIO_MODE enum 
 MPEG Audio mode. Possible values are:
 
V4L2_MPEG_AUDIO_MODE_STEREO Stereo
V4L2_MPEG_AUDIO_MODE_JOINT_STEREO Joint Stereo
V4L2_MPEG_AUDIO_MODE_DUAL Bilingual
V4L2_MPEG_AUDIO_MODE_MONO Mono
    
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_MPEG_AUDIO_MODE_EXTENSION_BOUND_4 Subbands 4-31 in intensity stereo
V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_8 Subbands 8-31 in intensity stereo
V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_12 Subbands 12-31 in intensity stereo
V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_16 Subbands 16-31 in intensity stereo
    
V4L2_CID_MPEG_AUDIO_EMPHASIS enum 
 Audio Emphasis. Possible values are:
 
V4L2_MPEG_AUDIO_EMPHASIS_NONE None
V4L2_MPEG_AUDIO_EMPHASIS_50_DIV_15_uS 50/15 microsecond emphasis
V4L2_MPEG_AUDIO_EMPHASIS_CCITT_J17 CCITT J.17
    
V4L2_CID_MPEG_AUDIO_CRC enum 
 CRC method. Possible values are:
 
V4L2_MPEG_AUDIO_CRC_NONE None
V4L2_MPEG_AUDIO_CRC_CRC16 16 bit parity check
    
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_MPEG_VIDEO_ENCODING_MPEG_1 MPEG-1 Video encoding
V4L2_MPEG_VIDEO_ENCODING_MPEG_2 MPEG-2 Video encoding
    
V4L2_CID_MPEG_VIDEO_ASPECT enum 
 Video aspect. Possible values are:
 
V4L2_MPEG_VIDEO_ASPECT_1x1  
V4L2_MPEG_VIDEO_ASPECT_4x3  
V4L2_MPEG_VIDEO_ASPECT_16x9  
V4L2_MPEG_VIDEO_ASPECT_221x100  
    
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_MPEG_VIDEO_BITRATE_MODE_VBR Variable bitrate
V4L2_MPEG_VIDEO_BITRATE_MODE_CBR Constant bitrate
    
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):
 
Bit 0:7V chrominance information
Bit 8:15U chrominance information
Bit 16:23Y luminance information
Bit 24:31Must be zero.

1.9.5.2. CX2341x MPEG Controls

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

IDType 
 Description
    
V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE enum 
 Sets the Spatial Filter mode (default MANUAL). Possible values are:
 
V4L2_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE_MANUAL Choose the filter manually
V4L2_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE_AUTO Choose the filter automatically
    
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_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_OFF No filter
V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_1D_HOR One-dimensional horizontal
V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_1D_VERT One-dimensional vertical
V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_2D_HV_SEPARABLE Two-dimensional separable
V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_2D_SYM_NON_SEPARABLE Two-dimensional symmetrical non-separable
    
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_MPEG_CX2341X_VIDEO_CHROMA_SPATIAL_FILTER_TYPE_OFF No filter
V4L2_MPEG_CX2341X_VIDEO_CHROMA_SPATIAL_FILTER_TYPE_1D_HOR One-dimensional horizontal
    
V4L2_CID_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER_MODE enum 
 Sets the Temporal Filter mode (default MANUAL). Possible values are:
 
V4L2_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER_MODE_MANUAL Choose the filter manually
V4L2_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER_MODE_AUTO Choose the filter automatically
    
V4L2_CID_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER integer (0-31) 
 The setting for the Temporal Filter. 0 = off, 31 = maximum. (Default is 8 for full-scale capturing and 0 for scaled capturing.)
    
V4L2_CID_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE enum 
 Median Filter Type (default OFF). Possible values are:
 
V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_OFF No filter
V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_HOR Horizontal filter
V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_VERT Vertical filter
V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_HOR_VERT Horizontal and vertical filter
V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_DIAG Diagonal filter
    
V4L2_CID_MPEG_CX2341X_VIDEO_LUMA_MEDIAN_FILTER_BOTTOM integer (0-255) 
 Threshold above which the luminance median filter is enabled (default 0)
    
V4L2_CID_MPEG_CX2341X_VIDEO_LUMA_MEDIAN_FILTER_TOP integer (0-255) 
 Threshold below which the luminance median filter is enabled (default 255)
    
V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_MEDIAN_FILTER_BOTTOM integer (0-255) 
 Threshold above which the chroma median filter is enabled (default 0)
    
V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_MEDIAN_FILTER_TOP integer (0-255) 
 Threshold below which the chroma median filter is enabled (default 255)
    
V4L2_CID_MPEG_CX2341X_STREAM_INSERT_NAV_PACKETS bool 
 The CX2341X MPEG encoder can insert one empty MPEG-2 PES packet into the stream between every four video frames. The packet size is 2048 bytes, including the packet_start_code_prefix and stream_id fields. The stream_id is 0xBF (private stream 2). The payload consists of 0x00 bytes, to be filled in by the application. 0 = do not insert, 1 = insert packets.

1.9.6. Camera Control Reference

The Camera class includes controls for mechanical (or equivalent digital) features of a device such as controllable lenses or sensors.

Table 1-4. Camera Control IDs

IDType 
 Description
    
V4L2_CID_CAMERA_CLASS class 
 The Camera class descriptor. Calling VIDIOC_QUERYCTRL for this control will return a description of this control class.
    
V4L2_CID_EXPOSURE_AUTO integer 
 Enables automatic adjustments of the exposure time and/or iris aperture. The effect of manual changes of the exposure time or iris aperture while these features are enabled is undefined, drivers should ignore such requests. Possible values are:
 
V4L2_EXPOSURE_AUTO Automatic exposure time, automatic iris aperture.
V4L2_EXPOSURE_MANUAL Manual exposure time, manual iris.
V4L2_EXPOSURE_SHUTTER_PRIORITY Manual exposure time, auto iris.
V4L2_EXPOSURE_APERTURE_PRIORITY Auto exposure time, manual iris.
    
V4L2_CID_EXPOSURE_ABSOLUTE integer 
 Determines the exposure time of the camera sensor. The exposure time is limited by the frame interval. Drivers should interpret the values as 100 µs units, where the value 1 stands for 1/10000th of a second, 10000 for 1 second and 100000 for 10 seconds.
    
V4L2_CID_EXPOSURE_AUTO_PRIORITY boolean 
 When V4L2_CID_EXPOSURE_AUTO is set to AUTO or SHUTTER_PRIORITY, this control determines if the device may dynamically vary the frame rate. By default this feature is disabled (0) and the frame rate must remain constant.
    
V4L2_CID_PAN_RELATIVE integer 
 This control turns the camera horizontally by the specified amount. The unit is undefined. A positive value moves the camera to the right (clockwise when viewed from above), a negative value to the left. A value of zero does not cause motion.
    
V4L2_CID_TILT_RELATIVE integer 
 This control turns the camera vertically by the specified amount. The unit is undefined. A positive value moves the camera up, a negative value down. A value of zero does not cause motion.
    
V4L2_CID_PAN_RESET boolean 
 When this control is set to TRUE (1), the camera moves horizontally to the default position.
    
V4L2_CID_TILT_RESET boolean 
 When this control is set to TRUE (1), the camera moves vertically to the default position.
    
V4L2_CID_PAN_ABSOLUTE integer 
 This control turns the camera horizontally to the specified position. Positive values move the camera to the right (clockwise when viewed from above), negative values to the left. Drivers should interpret the values as arc seconds, with valid values between -180 * 3600 and +180 * 3600 inclusive.
    
V4L2_CID_TILT_ABSOLUTE integer 
 This control turns the camera vertically to the specified position. Positive values move the camera up, negative values down. Drivers should interpret the values as arc seconds, with valid values between -180 * 3600 and +180 * 3600 inclusive.
    
V4L2_CID_FOCUS_ABSOLUTE integer 
 This control sets the focal point of the camera to the specified position. The unit is undefined. Positive values set the focus closer to the camera, negative values towards infinity.
    
V4L2_CID_FOCUS_RELATIVE integer 
 This control moves the focal point of the camera by the specified amount. The unit is undefined. Positive values move the focus closer to the camera, negative values towards infinity.
    
V4L2_CID_FOCUS_AUTO boolean 
 Enables automatic focus adjustments. The effect of manual focus adjustments while this feature is enabled is undefined, drivers should ignore such requests.
    

1.10. Data Formats

1.10.1. Data Format Negotiation

Different devices exchange different kinds of data with applications, for example video images, raw or sliced VBI data, RDS datagrams. Even within one kind many different formats are possible, in particular an abundance of image formats. Although drivers must provide a default and the selection persists across closing and reopening a device, applications should always negotiate a data format before engaging in data exchange. Negotiation means the application asks for a particular format and the driver selects and reports the best the hardware can do to satisfy the request. Of course applications can also just query the current selection.

A single mechanism exists to negotiate all data formats using the aggregate struct v4l2_format and the VIDIOC_G_FMT and VIDIOC_S_FMT ioctls. Additionally the VIDIOC_TRY_FMT ioctl can be used to examine what the hardware could do, without actually selecting a new data format. The data formats supported by the V4L2 API are covered in the respective device section in Chapter 4. For a closer look at image formats see Chapter 2.

The VIDIOC_S_FMT ioctl is a major turning-point in the initialization sequence. Prior to this point multiple panel applications can access the same device concurrently to select the current input, change controls or modify other properties. The first VIDIOC_S_FMT assigns a logical stream (video data, VBI data etc.) exclusively to one file descriptor.

Exclusive means no other application, more precisely no other file descriptor, can grab this stream or change device properties inconsistent with the negotiated parameters. A video standard change for example, when the new standard uses a different number of scan lines, can invalidate the selected image format. Therefore only the file descriptor owning the stream can make invalidating changes. Accordingly multiple file descriptors which grabbed different logical streams prevent each other from interfering with their settings. When for example video overlay is about to start or already in progress, simultaneous video capturing may be restricted to the same cropping and image size.

When applications omit the VIDIOC_S_FMT ioctl its locking side effects are implied by the next step, the selection of an I/O method with the VIDIOC_REQBUFS ioctl or implicit with the first read() or write() call.

Generally only one logical stream can be assigned to a file descriptor, the exception being drivers permitting simultaneous video capturing and overlay using the same file descriptor for compatibility with V4L and earlier versions of V4L2. Switching the logical stream or returning into "panel mode" is possible by closing and reopening the device. Drivers may support a switch using VIDIOC_S_FMT.

All drivers exchanging data with applications must support the VIDIOC_G_FMT and VIDIOC_S_FMT ioctl. Implementation of the VIDIOC_TRY_FMT is highly recommended but optional.


1.10.2. Image Format Enumeration

Apart of the generic format negotiation functions a special ioctl to enumerate all image formats supported by video capture, overlay or output devices is available.[11]

The VIDIOC_ENUM_FMT ioctl must be supported by all drivers exchanging image data with applications.

Important: Drivers are not supposed to convert image formats in kernel space. They must enumerate only formats directly supported by the hardware. If necessary driver writers should publish an example conversion routine or library for integration into applications.


1.11. Image Cropping, Insertion and Scaling

Some video capture devices can sample a subsection of the picture and shrink or enlarge it to an image of arbitrary size. We call these abilities cropping and scaling. Some video output devices can scale an image up or down and insert it at an arbitrary scan line and horizontal offset into a video signal.

Applications can use the following API to select an area in the video signal, query the default area and the hardware limits. Despite their name, the VIDIOC_CROPCAP, VIDIOC_G_CROP and VIDIOC_S_CROP ioctls apply to input as well as output devices.

Scaling requires a source and a target. On a video capture or overlay device the source is the video signal, and the cropping ioctls determine the area actually sampled. The target are images read by the application or overlaid onto the graphics screen. Their size (and position for an overlay) is negotiated with the VIDIOC_G_FMT and VIDIOC_S_FMT ioctls.

On a video output device the source are the images passed in by the application, and their size is again negotiated with the VIDIOC_G/S_FMT ioctls, or may be encoded in a compressed video stream. The target is the video signal, and the cropping ioctls determine the area where the images are inserted.

Source and target rectangles are defined even if the device does not support scaling or the VIDIOC_G/S_CRO