| <title>Video Capture Interface</title> | |
| <para>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.</para> | |
| <para>Conventionally V4L2 video capture devices are accessed through | |
| character device special files named <filename>/dev/video</filename> | |
| and <filename>/dev/video0</filename> to | |
| <filename>/dev/video63</filename> with major number 81 and minor | |
| numbers 0 to 63. <filename>/dev/video</filename> is typically a | |
| symbolic link to the preferred video device. Note the same device | |
| files are used for video output devices.</para> | |
| <section> | |
| <title>Querying Capabilities</title> | |
| <para>Devices supporting the video capture interface set the | |
| <constant>V4L2_CAP_VIDEO_CAPTURE</constant> or | |
| <constant>V4L2_CAP_VIDEO_CAPTURE_MPLANE</constant> flag in the | |
| <structfield>capabilities</structfield> field of &v4l2-capability; | |
| returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions | |
| they may also support the <link linkend="overlay">video overlay</link> | |
| (<constant>V4L2_CAP_VIDEO_OVERLAY</constant>) and the <link | |
| linkend="raw-vbi">raw VBI capture</link> | |
| (<constant>V4L2_CAP_VBI_CAPTURE</constant>) interface. At least one of | |
| the read/write or streaming I/O methods must be supported. Tuners and | |
| audio inputs are optional.</para> | |
| </section> | |
| <section> | |
| <title>Supplemental Functions</title> | |
| <para>Video capture devices shall support <link | |
| linkend="audio">audio input</link>, <link | |
| linkend="tuner">tuner</link>, <link linkend="control">controls</link>, | |
| <link linkend="crop">cropping and scaling</link> and <link | |
| linkend="streaming-par">streaming parameter</link> ioctls as needed. | |
| The <link linkend="video">video input</link> and <link | |
| linkend="standard">video standard</link> ioctls must be supported by | |
| all video capture devices.</para> | |
| </section> | |
| <section> | |
| <title>Image Format Negotiation</title> | |
| <para>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, | |
| &ie; 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.</para> | |
| <para>As usual these parameters are <emphasis>not</emphasis> reset | |
| at &func-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.</para> | |
| <para>Cropping initialization at minimum requires to reset the | |
| parameters to defaults. An example is given in <xref | |
| linkend="crop" />.</para> | |
| <para>To query the current image format applications set the | |
| <structfield>type</structfield> field of a &v4l2-format; to | |
| <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> or | |
| <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant> and call the | |
| &VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill | |
| the &v4l2-pix-format; <structfield>pix</structfield> or the | |
| &v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member of the | |
| <structfield>fmt</structfield> union.</para> | |
| <para>To request different parameters applications set the | |
| <structfield>type</structfield> field of a &v4l2-format; as above and | |
| initialize all fields of the &v4l2-pix-format; | |
| <structfield>vbi</structfield> member of the | |
| <structfield>fmt</structfield> union, or better just modify the | |
| results of <constant>VIDIOC_G_FMT</constant>, 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 | |
| <constant>VIDIOC_G_FMT</constant> does.</para> | |
| <para>Like <constant>VIDIOC_S_FMT</constant> the | |
| &VIDIOC-TRY-FMT; ioctl can be used to learn about hardware limitations | |
| without disabling I/O or possibly time consuming hardware | |
| preparations.</para> | |
| <para>The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane; | |
| are discussed in <xref linkend="pixfmt" />. See also the specification of the | |
| <constant>VIDIOC_G_FMT</constant>, <constant>VIDIOC_S_FMT</constant> | |
| and <constant>VIDIOC_TRY_FMT</constant> ioctls for details. Video | |
| capture devices must implement both the | |
| <constant>VIDIOC_G_FMT</constant> and | |
| <constant>VIDIOC_S_FMT</constant> ioctl, even if | |
| <constant>VIDIOC_S_FMT</constant> ignores all requests and always | |
| returns default parameters as <constant>VIDIOC_G_FMT</constant> does. | |
| <constant>VIDIOC_TRY_FMT</constant> is optional.</para> | |
| </section> | |
| <section> | |
| <title>Reading Images</title> | |
| <para>A video capture device may support the <link | |
| linkend="rw">read() function</link> and/or streaming (<link | |
| linkend="mmap">memory mapping</link> or <link | |
| linkend="userp">user pointer</link>) I/O. See <xref | |
| linkend="io" /> for details.</para> | |
| </section> |