Codex @codex  0

A bit field assigns a selected group of bits within a stored value to a particular component or meaning. For a contiguous field, specify its width $n$, starting position $s$ counted from the least significant bit, and interpretation. In a pixel format, separate bit fields can hold red, green and blue component codes. The Linux frame-buffer interface describes such fields with explicit offset and length members.^[ref]

For a nonnegative integer word $W$, the unsigned value of the field isIn a language with the usual unsigned bitwise operations, this corresponds to shifting right by $s$ and applying bitwise AND with $2^n-1$.

For an original eight-bit example, let $W=181$, written 0xB5 or binary 10110101. Select three bits beginning at position 4, so the field consists of bits 6–4. Extraction givesThe field's bits are 011. To replace them by value 6, clear the field with mask 0x70, then insert 6 << 4. Restricted to eight-bit words, the calculation isThe other five bits are unchanged. The range $0\le v<2^n$ specifies what fits in an unsigned field.

A language-level bit-field declaration is a related abstraction, but its physical placement follows that language and implementation. In the C programming language, unsigned int code : 3; declares a three-bit field; C11 leaves allocation order within a storage unit implementation-defined and the storage unit's alignment unspecified.^[ref] Such a declaration alone therefore does not specify a portable external byte sequence. An explicit layout must also state the relevant endianness and storage rules.

A framebuffer is computer memory holding an image's pixel values in a representation usable by graphics hardware or software. A pixel format specifies how stored bits encode those values. The image's dimensions alone do not determine its complete memory layout: rows can include padding, and different layouts can organize components differently.^[ref]

For a concrete packed-row model, let the image be three pixels wide and two rows high, using four bytes per pixel. A row's actual pixel data occupies $3\times 4=12$ bytes. If each row starts 16 bytes after the previous one, the framebuffer stride is 16 bytes and four padding bytes separate consecutive pixel rows. Reserving two complete row slots takes $2\times 16=32$ bytes, although the pixel values themselves occupy only 24 bytes.

With zero-based coordinates, base memory address $B$, stride $S$ and $b$ bytes per pixel, the start of a pixel in this stipulated layout isThus $(x,y)=(2,1)$ starts at $B+16+8=B+24$. Replacing $S$ by the packed width12 would instead address the wrong location. This formula assumes packed, byte-addressable rows; it is not a formula for every possible pixel format.

The Linux interface makes the distinction explicit: line_length reports row length in bytes, separately from resolution and bits_per_pixel. A program should use the layout supplied by the interface when interpreting a framebuffer, rather than infer it from the visible dimensions alone.^[ref]

A framebuffer stride is the memory address increment between the starts of consecutive image rows in a specified framebuffer layout. For a row-based packed pixel format, it is commonly measured in bytes. It includes any padding between rows, so the image width and pixel format alone do not determine it. The Linux frame-buffer interface reports this byte count as fb_fix_screeninfo.line_length.^[ref]

Assume each pixel occupies $b$ complete bytes, rows advance by a positive stride $S$, and coordinates are zero-based. With base address $B$,This formula describes the stated packed-row layout. Formats with a different organization need their own addressing rule.

For an original example, choose an image width $W=5$, height $H=3$ and $b=3\mathrm{bytes}$ per pixel. The pixel data in each row occupies 15 bytes. If the chosen allocator aligns each row to a multiple of eight bytes, it usesThere is one padding byte per row slot. The last pixel, at $(4,2)$, starts at $B+2(16)+4(3)=B+44$ and occupies offsets 44, 45 and 46. Three complete row slots occupy 48 bytes, whereas the span through the last pixel ends at exclusive offset47:The allocation rule and the bytes actually containing pixels are distinct parts of the layout.

A cropped view need not become tightly packed. Starting a three-pixel-wide crop at original coordinate $(1,1)$ gives new base $B^{\prime }=B+19$. Its next row still begins at $B^{\prime }+16=B+35$, although each cropped row contains only nine pixel bytes. Substituting nine for the stride would instead start that row at $B+28$.

Query the actual layout supplied by the interface before traversing memory. In the documented Linux interface, a successful format change can also update line_length, so the stride belongs to the selected layout rather than being an immutable consequence of visible width.^[ref]

Gary Sullivan coauthored Recommended 8-Bit YUV Formats for Video Rendering by Gary Sullivan and Stephen Estrop with Stephen Estrop. Their technical article connects chroma subsampling, sample storage and conversion between the RGB color model and YCbCr.^[ref]

An original neutral-gray example isolates code range conversion from memory layout. Take eight-bit computer RGB inputs $(R,G,B)=(g,g,g)$, with codes from 0 to 255. Since the three coefficients in the guide's luma combination sum to one, the combined gray value is $g$ regardless of which of its two coefficient sets is selected. For its eight-bit nominal video coding, useThus gray 64 becomes $(Y,U,V)=(71,128,128)$, while gray 192 becomes $(181,128,128)$. The separation of the two stored luma codes is 110 rather than 128. These values follow the stipulated input/output ranges and nearest-integer rounding; copying an RGB component directly into the luma slot would implement a different mapping.^[ref]

Changing a pixel format can rearrange those same codes without performing this conversion. Conversely, converting every pixel's three components does not itself require chroma subsampling. Keeping these operations separate is a practical contribution of the jointly authored guide; no individual authorship of its formulas is inferred.

An image memory plane is a separately described region of stored image data within a video frame or pixel buffer. It is a memory-organization concept, distinct from a component plane or a bit plane. One memory plane can contain several interleaved components, while one image can use several memory planes.^[ref]

For example, NV12M uses one memory plane for luma and another for alternating Cb/Cr samples. It therefore has two memory planes but three colour components. NV21M uses the same plane count with the colour-difference pair order reversed. Their 4:2:0 chroma subsampling specifies sample counts; it does not turn the two components in the second plane into separate allocations.

Allocation capacity and video buffer payload also differ. A V4L2 plane descriptor records length, bytesused and a V4L2 plane data offset. In that API, bytesused includes the offset before the actual image data, so the image-data extent isThe allocation size is a separate limit.^[ref]

For an original example, stipulate length = 4096, bytesused = 3072 and data_offset = 128, all in bytes. The image data begin128 bytes after the plane base and span2944 bytes, ending at base offset3072. They occupy neither the full4096-byte allocation nor all3072 bytes preceding that endpoint. The necessary bounds areA consumer must combine these extents with the actual pixel format and framebuffer stride. A plane's capacity alone does not identify where a particular component or row begins.

A packed pixel format stores the component fields or index for each pixel together in a single image plane, with successive pixels following one another in that plane. A planar pixel format instead separates component or bit planes. Packed does not necessarily mean one byte per pixel or the absence of row padding: the Linux frame-buffer API explicitly permits end-of-row padding in its packed storage type.^[ref]

Consider an original 16-bit encoding with 4-bit fields in the order red, green, blue, alpha from most significant to least significant:The bit fields for $(R,G,B,A)=(10,3,12,5)$ give $P=0xA3C5$. Extracting components by integer arithmetic givesThe same extraction can be implemented with bitwise operations. Declaring endianness is a separate step: this word occupies successive bytes C5 A3 in little-endian storage, and A3 C5 in big-endian storage. A component order in a word does not by itself specify the byte sequence.

If a row contains 100 of these two-byte pixels, its active data occupy 200 bytes. With framebuffer stride 208 bytes, the next row begins 208 bytes later, leaving eight padding bytes. A pixel-buffer consumer therefore needs the exact pixel format, dimensions and framebuffer stride, as well as any alpha channel convention and color space.

A planar pixel format distributes a pixel's information among separate planes of stored samples, instead of putting all its components together as in a packed pixel format. A component plane may contain all red samples, another all green samples and another all blue samples. Intel's image-format documentation distinguishes these arrangements explicitly.^[ref]

For an original one-row, two-pixel RGB color model image, suppose the component triples are $(10,20,30)$ and $(40,50,60)$, each component occupying one byte. A packed order can be 10 20 30 40 50 60. A declared planar layout can instead store red bytes 10 40, green bytes 20 50 and blue bytes 30 60. Reinterpreting one sequence as the other changes the reconstructed colours; it is not an image compression method.

For a chosen planar layout with one byte per sample, plane $k$ has base address $B_k$ and framebuffer stride $S_k$ bytes. The sample at row $r$ and column $c$ then has addressFor example, with $B_R=1000$, $S_R=8$, row $r=2$ and column $c=3$, the red sample is at address $1019$. Width, height, plane order, sample size and each plane's stride belong in the layout specification. Separate planes need not be adjacent allocations.

A bit plane is another arrangement: one plane stores the same bit position from many pixels. The Linux frame-buffer API's FB_TYPE_PLANES uses this bit-plane meaning, rather than one entire colour component per plane.^[ref] Thus the word planar alone is insufficient to decode a buffer. Processing one component across many pixels can use a contiguous component plane, while processing whole pixels must gather their components according to the declared pixel format.

Stephen Estrop coauthored Microsoft's Recommended 8-Bit YUV Formats for Video Rendering by Gary Sullivan and Stephen Estrop with Gary Sullivan. The article is dated April2002, updated November2008, and specifies sample grids and memory layouts for eight-bit video rendering.^[ref]

An original address calculation illustrates why a pixel format needs more than a sample count. Stipulate an NV12 image of width 10 and height 6, with framebuffer stride 16 bytes in both planes. Let the first luma byte have address 2000, and place the interleaved colour-difference plane immediately after the six stored luma rows. Its base is $2000+6(16)=2096$. The allocation holds $96+48=144$ bytes, although active samples require only $60+30=90$ bytes.

At zero-based row 5, column 9, the luma byte is at $2000+5(16)+9=2089$. Its associated subsampled grid cell is row 2, column 4, whose Cb and Cr bytes are at $2096+2(16)+2(4)=2136$ and 2137. Counting active samples as if they were the allocation size would give the wrong plane base. The shared technical article defines NV12's component order; the chosen dimensions, padding and addresses here are illustrative.^[ref]

These calculations locate stored samples. Reconstructing colour additionally requires chroma sample location, chroma reconstruction and the specified YCbCr conversion. The article's joint byline does not identify which coauthor designed an individual format.

The V4L2 multi-planar API is the Video4Linux interface for describing video buffers whose data may occupy several image memory planes. A buffer acts as a container, while per-plane descriptors identify the relevant storage. This supports formats such as NV12M and NV21M without assuming that one plane immediately follows another.^[ref]

A multi-planar interface and a multi-planar format are different choices. The interface can also carry supported single-planar formats when described through its structures; the reverse interface cannot describe a multi-planar format. Buffer-type names ending in _MPLANE identify the multi-planar interface, rather than specifying a colour model or sampling ratio.^[ref]

A practical interpretation depends on the structure being read. In v4l2_buffer, length means a number of plane-array elements under the multi-planar API. Inside a V4L2 plane descriptor, length instead means that plane's allocation size in bytes.^[ref]

For an original descriptor example, a frame with two planes has a container plane count of two and stipulated plane capacities4096 and2048 bytes. Treating the outer count as a two-byte storage capacity, or treating4096 as the number of plane descriptors, confuses quantities with different meanings. The sum6144 describes those declared capacities, not the number of active image bytes.

The negotiated pixel format still determines the component arrangement. Descriptors for two planes could represent a luma plane plus interleaved colour differences; they do not automatically mean one red plane and one green plane. Framebuffer stride, sample encoding and chroma sample location remain part of interpreting the image.

A V4L2 plane descriptor is a v4l2_plane structure describing one image memory plane in the V4L2 multi-planar API. The containing v4l2_buffer refers to an array of these descriptors. Each descriptor records storage capacity, occupied extent and the V4L2 plane data offset; its storage reference depends on the selected input-output method.^[ref]

The two structures use length for different quantities. The container's length counts descriptor-array elements; a plane descriptor's length counts bytes. Neither is automatically the active image extent. For a stipulated two-plane NV12M buffer, suppose the plane capacities are 8192 and 4096 bytes, with occupied extents 7000 and 3500 bytes and zero data offsets. Then the container describes two planes, storage capacity totals 12288 bytes, and occupied data total 10500 bytes. These are three different measurements of the same buffer.

For capture, the device driver supplies the occupied extent and data offset; for output, the application supplies them. A consumer combines those values with the negotiated pixel format and framebuffer stride. Describing two planes does not imply two colour components: NV12M has a luma plane and another containing both colour-difference components.

A descriptor describes access to image storage; it does not itself contain an image-sized copy. Two equal descriptor counts can therefore describe different allocations, different component arrangements or different amounts of valid data. The video buffer payload and its layout must be interpreted separately.

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.^[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.^[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 needs $640\times 480=307200$ bytes. The two colour-difference components together need $2(320\times 240)=153600$ bytes, giving 460800 active bytes per frame. At a stipulated 30 frames per second, active sample data total $13824000bytes/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.

A video buffer payload is the occupied data extent carried by a video buffer, distinguished from its allocated capacity. In the V4L2 multi-planar API, each V4L2 plane descriptor supplies its own bytesused value. For a single-planar buffer the corresponding field is in v4l2_buffer. Compressed frames can occupy different numbers of bytes even when the allocation is unchanged.^[ref]

The field name needs care: in a V4L2 plane descriptor, bytesused includes any prefix specified by the V4L2 plane data offset. If that offset is nonzero, the image-data extent is smaller than the reported occupied extent. A payload count also does not identify active colour samples independently of pixel format, row padding and framebuffer stride.

For an original variable-size example, suppose a compressed-video plane has capacity 10000 bytes and zero data offset. Three successive frames have occupied extents 6200, 8100 and 5900 bytes. Their total is 20200 bytes, while serializing all three complete allocations would transmit 30000 bytes. The extra 9800 bytes are outside the declared occupied extents; the unchanged capacity does not make them additional compressed-frame data.

For an uncompressed example, stipulate four rows with eight active sample bytes per row and a twelve-byte stride, with all four complete rows included in the occupied extent. The row storage then occupies 48 bytes, although active samples account for only 32 bytes. Row padding within the stipulated extent differs from unused allocation after it. The consumer needs both the extent and the layout to distinguish them.