Video4Linux (source code)

= Video4Linux
{c}

\b[Video4Linux] is the <Linux kernel> subsystem through which applications control supported video-related hardware and exchange data with it. Its version-two <application programming interface> is called V4L2. A <device driver> exposes the applicable device interfaces; applications use <file descriptors> and control operations rather than directly programming the hardware registers. The kernel specification describes video capture/output, radio and related device-node types.<Opening devices and querying capabilities in the Linux Kernel video API documentation>[Opening and Closing Devices, §§1.1.1–1.1.2 and §1.1.6]{ref}

A <video device node> such as `/dev/video0` is an entry point to an interface, not a promise about a camera's identity or its supported formats. Device numbering can depend on discovery order. After opening a device, an application queries its capabilities with `VIDIOC_QUERYCAP`; the available operations depend on the device.<Opening devices and querying capabilities in the Linux Kernel video API documentation>[§1.1.2, device naming notes; Querying Capabilities, §1.2]{ref}

For an original frame-storage example, suppose a device supports <NV12M> at width 640 and height 480, with eight-bit samples, even dimensions and no padding. Full-resolution <luma (video)> needs $640\times480=307200$ <bytes>. The two colour-difference components together need $2(320\times240)=153600$ bytes, giving 460800 active bytes per frame. At a stipulated 30 frames per second, active sample data total $13824000\,\mathrm{bytes/s}$. Allocation padding, other transport data and actual timing are separate quantities.

The <V4L2 multi-planar API> can describe those separately stored <image memory planes>; each <V4L2 plane descriptor> supplies that plane's extents. A negotiated <pixel format> and <framebuffer stride> tell an application how to interpret the received data. A successful device open alone establishes none of those layout choices.