Table of Contents
Video capture devices sample an analog video signal and store the digitized images in memory. Today nearly all devices can capture at full 25 or 30 frames/second. With this interface applications can control the capture process and move images from the driver into user space.
Conventionally V4L2 video capture devices are accessed through
character device special files named /dev/video
and /dev/video0 to
/dev/video63 with major number 81 and minor
numbers 0 to 63. /dev/video is typically a
symbolic link to the preferred video device. Note the same device
files are used for video output devices.
Devices supporting the video capture interface set the
V4L2_CAP_VIDEO_CAPTURE or
V4L2_CAP_VIDEO_CAPTURE_MPLANE flag in the
capabilities field of struct v4l2_capability
returned by the VIDIOC_QUERYCAP ioctl. As secondary device functions
they may also support the video overlay
(V4L2_CAP_VIDEO_OVERLAY) and the raw VBI capture
(V4L2_CAP_VBI_CAPTURE) interface. At least one of
the read/write or streaming I/O methods must be supported. Tuners and
audio inputs are optional.
Video capture devices shall support audio input, tuner, controls, cropping and scaling and streaming parameter ioctls as needed. The video input and video standard ioctls must be supported by all video capture devices.
The result of a capture operation is determined by cropping and image format parameters. The former select an area of the video picture to capture, the latter how images are stored in memory, i. e. in RGB or YUV format, the number of bits per pixel or width and height. Together they also define how images are scaled in the process.
As usual these parameters are not reset
at open() time to permit Unix tool chains, programming a device
and then reading from it as if it was a plain file. Well written V4L2
applications ensure they really get what they want, including cropping
and scaling.
Cropping initialization at minimum requires to reset the parameters to defaults. An example is given in the section called “Image Cropping, Insertion and Scaling”.
To query the current image format applications set the
type field of a struct v4l2_format to
V4L2_BUF_TYPE_VIDEO_CAPTURE or
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE and call the
VIDIOC_G_FMT ioctl with a pointer to this structure. Drivers fill
the struct v4l2_pix_format pix or the
struct v4l2_pix_format_mplane pix_mp member of the
fmt union.
To request different parameters applications set the
type field of a struct v4l2_format as above and
initialize all fields of the struct v4l2_pix_format
vbi member of the
fmt union, or better just modify the
results of VIDIOC_G_FMT, and call the
VIDIOC_S_FMT ioctl with a pointer to this structure. Drivers may
adjust the parameters and finally return the actual parameters as
VIDIOC_G_FMT does.
Like VIDIOC_S_FMT the
VIDIOC_TRY_FMT ioctl can be used to learn about hardware limitations
without disabling I/O or possibly time consuming hardware
preparations.
The contents of struct v4l2_pix_format and struct v4l2_pix_format_mplane
are discussed in Chapter 2, Image Formats. See also the specification of the
VIDIOC_G_FMT, VIDIOC_S_FMT
and VIDIOC_TRY_FMT ioctls for details. Video
capture devices must implement both the
VIDIOC_G_FMT and
VIDIOC_S_FMT ioctl, even if
VIDIOC_S_FMT ignores all requests and always
returns default parameters as VIDIOC_G_FMT does.
VIDIOC_TRY_FMT is optional.
A video capture device may support the read() function and/or streaming (memory mapping or user pointer) I/O. See Chapter 3, Input/Output for details.