Saturday, October 25, 2014


Video for Linux or V4L is a set of APIs and driver framework for video capture applications and for O/P devices. It supports many USB webcams, TV tuners and other O/P devices.It is integrated into the Linux Kernel code. V4L2 is the second version of V4L.


Operations performed on a V4L2 device-

Opening the device

• Changing device properties, selecting a video and audio input, video standard, picture brightness e.t.c
• Negotiating a data format
• Negotiating an input/output method
• The actual input/output loop

• Closing the device

1. Opening and Closing the device

  • V4L2 drivers are implemented as kernel modules.
  • They are loaded automatically when the device is first opened.(can be loaded manually too).
  • The driver plugs into videodev kernel module.
  • This module provides helper function and a common application interface to all the drivers attached.
  • All V4L2 devices registers their device nodes with same major number 81 and different minor numbers.

What if the same driver supports multiple related function?

In this case the driver registers different minor numbers for the different operations.

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.

Can a V4L2 device be opened more than once?

Yes, this feature can be implemented in the V4L2 driver. But data exchange is not permitted.
When the driver supports stream sharing anyway it must be implemented
transparently. The V4L2 API does not specify how conflicts are solved.

2.Querying Capabilities

All V4L2 drivers must support VIDIOC_QUERYCAP ioctl. Applications should always call this ioctl after opening the device.This ioctl is available to query the functions, capabilities 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.

Application Priority

All applications are provided a default medium priority when opened. It is possible that we want to use two different applications with different priorities , for eg. we would want one application to run in low priority in background and one application is foreground(high priority). V4L2 defines the VIDIOC_G_PRIORITY and VIDIOC_S_PRIORITY ioctls to request and query the access priority associate with a file descriptor.After using query capability ioctl the application can use VIDIOC_S_PRIORITY to set a different priority.

3. Video Inputs and Outputs

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

4. Audio Inputs and Outputs

Audio and video inputs and outputs are associated. Selecting a video source also selects an audio source.
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 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.

5. 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.To enumerate and query the attributes of the supported standards applications use the VIDIOC_ENUMSTD ioctl.
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.

When we deal with USB camera, the notion of video standards make little sense.
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

6. V4L2 Controls

Devices have different set of controls like brightness, contrast, saturation which is generally presented to the user in form of user interface.As devices vary the controls associated with that device varies too.
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 below 

Applications can enumerate the available controls with the VIDIOC_QUERYCTRL and
They can 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.

7. Data Formats

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 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.
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.
The VIDIOC_ENUM_FMT ioctl must be supported by all drivers exchanging image data with


No comments:

Post a Comment