Video device node (source code)

= Video device node

A \b[video device node] is a <device node> through which an application accesses a supported video or metadata interface in <Video4Linux>. A conventional path is `/dev/video0`, but the name identifies a kernel interface rather than a persistent physical-camera identity. <Device drivers> register the interfaces, and applications open them to obtain <file descriptors> for the appropriate operations.<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 single hardware peripheral can expose several interfaces. Conversely, a path numbered zero can refer to different hardware after discovery order changes. The kernel documentation identifies `/dev/v4l/by-id/` and `/dev/v4l/by-path/` links as alternatives for identifying devices independently of transient numbering.<Opening devices and querying capabilities in the Linux Kernel video API documentation>[§1.1.2, naming notes and example device links]{ref}

For an original selection example, suppose cameras A and B are discovered in that order and receive paths `/dev/video0` and `/dev/video1`. On another boot B is discovered first, reversing those assignments. A configuration containing only `/dev/video0` then selects a different camera while remaining a valid path. Identifying the intended hardware and querying the opened interface's capabilities addresses two separate questions.

The returned <file descriptor> refers to an open instance; it is not the camera number. An application may receive descriptor 7 when opening `/dev/video0`, and another application may also have a descriptor 7 referring to another object in its own descriptor table. <File descriptors> are local process handles, while the device path belongs to the <file system> namespace.

Before interpreting data, query the interface with `VIDIOC_QUERYCAP` and negotiate its supported <pixel format>. A <video device node> alone does not imply support for <NV12M>, a chosen image size or the <V4L2 multi-planar API>. The resulting <image memory planes> and <video buffer payload> must follow the actual negotiated interface.