1.. Permission is granted to copy, distribute and/or modify this 2.. document under the terms of the GNU Free Documentation License, 3.. Version 1.1 or any later version published by the Free Software 4.. Foundation, with no Invariant Sections, no Front-Cover Texts 5.. and no Back-Cover Texts. A copy of the license is included at 6.. Documentation/userspace-api/media/fdl-appendix.rst. 7.. 8.. TODO: replace it to GFDL-1.1-or-later WITH no-invariant-sections 9 10.. _buffer: 11 12******* 13Buffers 14******* 15 16A buffer contains data exchanged by application and driver using one of 17the Streaming I/O methods. In the multi-planar API, the data is held in 18planes, while the buffer structure acts as a container for the planes. 19Only pointers to buffers (planes) are exchanged, the data itself is not 20copied. These pointers, together with meta-information like timestamps 21or field parity, are stored in a struct :c:type:`v4l2_buffer`, 22argument to the :ref:`VIDIOC_QUERYBUF`, 23:ref:`VIDIOC_QBUF <VIDIOC_QBUF>` and 24:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. In the multi-planar API, 25some plane-specific members of struct :c:type:`v4l2_buffer`, 26such as pointers and sizes for each plane, are stored in struct 27struct :c:type:`v4l2_plane` instead. In that case, struct 28struct :c:type:`v4l2_buffer` contains an array of plane structures. 29 30Dequeued video buffers come with timestamps. The driver decides at which 31part of the frame and with which clock the timestamp is taken. Please 32see flags in the masks ``V4L2_BUF_FLAG_TIMESTAMP_MASK`` and 33``V4L2_BUF_FLAG_TSTAMP_SRC_MASK`` in :ref:`buffer-flags`. These flags 34are always valid and constant across all buffers during the whole video 35stream. Changes in these flags may take place as a side effect of 36:ref:`VIDIOC_S_INPUT <VIDIOC_G_INPUT>` or 37:ref:`VIDIOC_S_OUTPUT <VIDIOC_G_OUTPUT>` however. The 38``V4L2_BUF_FLAG_TIMESTAMP_COPY`` timestamp type which is used by e.g. on 39mem-to-mem devices is an exception to the rule: the timestamp source 40flags are copied from the OUTPUT video buffer to the CAPTURE video 41buffer. 42 43 44Interactions between formats, controls and buffers 45================================================== 46 47V4L2 exposes parameters that influence the buffer size, or the way data is 48laid out in the buffer. Those parameters are exposed through both formats and 49controls. One example of such a control is the ``V4L2_CID_ROTATE`` control 50that modifies the direction in which pixels are stored in the buffer, as well 51as the buffer size when the selected format includes padding at the end of 52lines. 53 54The set of information needed to interpret the content of a buffer (e.g. the 55pixel format, the line stride, the tiling orientation or the rotation) is 56collectively referred to in the rest of this section as the buffer layout. 57 58Controls that can modify the buffer layout shall set the 59``V4L2_CTRL_FLAG_MODIFY_LAYOUT`` flag. 60 61Modifying formats or controls that influence the buffer size or layout require 62the stream to be stopped. Any attempt at such a modification while the stream 63is active shall cause the ioctl setting the format or the control to return 64the ``EBUSY`` error code. In that case drivers shall also set the 65``V4L2_CTRL_FLAG_GRABBED`` flag when calling 66:c:func:`VIDIOC_QUERYCTRL` or :c:func:`VIDIOC_QUERY_EXT_CTRL` for such a 67control while the stream is active. 68 69.. note:: 70 71 The :c:func:`VIDIOC_S_SELECTION` ioctl can, depending on the hardware (for 72 instance if the device doesn't include a scaler), modify the format in 73 addition to the selection rectangle. Similarly, the 74 :c:func:`VIDIOC_S_INPUT`, :c:func:`VIDIOC_S_OUTPUT`, :c:func:`VIDIOC_S_STD` 75 and :c:func:`VIDIOC_S_DV_TIMINGS` ioctls can also modify the format and 76 selection rectangles. When those ioctls result in a buffer size or layout 77 change, drivers shall handle that condition as they would handle it in the 78 :c:func:`VIDIOC_S_FMT` ioctl in all cases described in this section. 79 80Controls that only influence the buffer layout can be modified at any time 81when the stream is stopped. As they don't influence the buffer size, no 82special handling is needed to synchronize those controls with buffer 83allocation and the ``V4L2_CTRL_FLAG_GRABBED`` flag is cleared once the 84stream is stopped. 85 86Formats and controls that influence the buffer size interact with buffer 87allocation. The simplest way to handle this is for drivers to always require 88buffers to be reallocated in order to change those formats or controls. In 89that case, to perform such changes, userspace applications shall first stop 90the video stream with the :c:func:`VIDIOC_STREAMOFF` ioctl if it is running 91and free all buffers with the :c:func:`VIDIOC_REQBUFS` ioctl if they are 92allocated. After freeing all buffers the ``V4L2_CTRL_FLAG_GRABBED`` flag 93for controls is cleared. The format or controls can then be modified, and 94buffers shall then be reallocated and the stream restarted. A typical ioctl 95sequence is 96 97 #. VIDIOC_STREAMOFF 98 #. VIDIOC_REQBUFS(0) 99 #. VIDIOC_S_EXT_CTRLS 100 #. VIDIOC_S_FMT 101 #. VIDIOC_REQBUFS(n) 102 #. VIDIOC_QBUF 103 #. VIDIOC_STREAMON 104 105The second :c:func:`VIDIOC_REQBUFS` call will take the new format and control 106value into account to compute the buffer size to allocate. Applications can 107also retrieve the size by calling the :c:func:`VIDIOC_G_FMT` ioctl if needed. 108 109.. note:: 110 111 The API doesn't mandate the above order for control (3.) and format (4.) 112 changes. Format and controls can be set in a different order, or even 113 interleaved, depending on the device and use case. For instance some 114 controls might behave differently for different pixel formats, in which 115 case the format might need to be set first. 116 117When reallocation is required, any attempt to modify format or controls that 118influences the buffer size while buffers are allocated shall cause the format 119or control set ioctl to return the ``EBUSY`` error. Any attempt to queue a 120buffer too small for the current format or controls shall cause the 121:c:func:`VIDIOC_QBUF` ioctl to return a ``EINVAL`` error. 122 123Buffer reallocation is an expensive operation. To avoid that cost, drivers can 124(and are encouraged to) allow format or controls that influence the buffer 125size to be changed with buffers allocated. In that case, a typical ioctl 126sequence to modify format and controls is 127 128 #. VIDIOC_STREAMOFF 129 #. VIDIOC_S_EXT_CTRLS 130 #. VIDIOC_S_FMT 131 #. VIDIOC_QBUF 132 #. VIDIOC_STREAMON 133 134For this sequence to operate correctly, queued buffers need to be large enough 135for the new format or controls. Drivers shall return a ``ENOSPC`` error in 136response to format change (:c:func:`VIDIOC_S_FMT`) or control changes 137(:c:func:`VIDIOC_S_CTRL` or :c:func:`VIDIOC_S_EXT_CTRLS`) if buffers too small 138for the new format are currently queued. As a simplification, drivers are 139allowed to return a ``EBUSY`` error from these ioctls if any buffer is 140currently queued, without checking the queued buffers sizes. 141 142Additionally, drivers shall return a ``EINVAL`` error from the 143:c:func:`VIDIOC_QBUF` ioctl if the buffer being queued is too small for the 144current format or controls. Together, these requirements ensure that queued 145buffers will always be large enough for the configured format and controls. 146 147Userspace applications can query the buffer size required for a given format 148and controls by first setting the desired control values and then trying the 149desired format. The :c:func:`VIDIOC_TRY_FMT` ioctl will return the required 150buffer size. 151 152 #. VIDIOC_S_EXT_CTRLS(x) 153 #. VIDIOC_TRY_FMT() 154 #. VIDIOC_S_EXT_CTRLS(y) 155 #. VIDIOC_TRY_FMT() 156 157The :c:func:`VIDIOC_CREATE_BUFS` ioctl can then be used to allocate buffers 158based on the queried sizes (for instance by allocating a set of buffers large 159enough for all the desired formats and controls, or by allocating separate set 160of appropriately sized buffers for each use case). 161 162 163.. c:type:: v4l2_buffer 164 165struct v4l2_buffer 166================== 167 168.. tabularcolumns:: |p{2.8cm}|p{2.5cm}|p{1.6cm}|p{10.2cm}| 169 170.. cssclass:: longtable 171 172.. flat-table:: struct v4l2_buffer 173 :header-rows: 0 174 :stub-columns: 0 175 :widths: 1 2 10 176 177 * - __u32 178 - ``index`` 179 - Number of the buffer, set by the application except when calling 180 :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>`, then it is set by the 181 driver. This field can range from zero to the number of buffers 182 allocated with the :ref:`VIDIOC_REQBUFS` ioctl 183 (struct :c:type:`v4l2_requestbuffers` 184 ``count``), plus any buffers allocated with 185 :ref:`VIDIOC_CREATE_BUFS` minus one. 186 * - __u32 187 - ``type`` 188 - Type of the buffer, same as struct 189 :c:type:`v4l2_format` ``type`` or struct 190 :c:type:`v4l2_requestbuffers` ``type``, set 191 by the application. See :c:type:`v4l2_buf_type` 192 * - __u32 193 - ``bytesused`` 194 - The number of bytes occupied by the data in the buffer. It depends 195 on the negotiated data format and may change with each buffer for 196 compressed variable size data like JPEG images. Drivers must set 197 this field when ``type`` refers to a capture stream, applications 198 when it refers to an output stream. If the application sets this 199 to 0 for an output stream, then ``bytesused`` will be set to the 200 size of the buffer (see the ``length`` field of this struct) by 201 the driver. For multiplanar formats this field is ignored and the 202 ``planes`` pointer is used instead. 203 * - __u32 204 - ``flags`` 205 - Flags set by the application or driver, see :ref:`buffer-flags`. 206 * - __u32 207 - ``field`` 208 - Indicates the field order of the image in the buffer, see 209 :c:type:`v4l2_field`. This field is not used when the buffer 210 contains VBI data. Drivers must set it when ``type`` refers to a 211 capture stream, applications when it refers to an output stream. 212 * - struct timeval 213 - ``timestamp`` 214 - For capture streams this is time when the first data byte was 215 captured, as returned by the :c:func:`clock_gettime()` function 216 for the relevant clock id; see ``V4L2_BUF_FLAG_TIMESTAMP_*`` in 217 :ref:`buffer-flags`. For output streams the driver stores the 218 time at which the last data byte was actually sent out in the 219 ``timestamp`` field. This permits applications to monitor the 220 drift between the video and system clock. For output streams that 221 use ``V4L2_BUF_FLAG_TIMESTAMP_COPY`` the application has to fill 222 in the timestamp which will be copied by the driver to the capture 223 stream. 224 * - struct :c:type:`v4l2_timecode` 225 - ``timecode`` 226 - When the ``V4L2_BUF_FLAG_TIMECODE`` flag is set in ``flags``, this 227 structure contains a frame timecode. In 228 :c:type:`V4L2_FIELD_ALTERNATE <v4l2_field>` mode the top and 229 bottom field contain the same timecode. Timecodes are intended to 230 help video editing and are typically recorded on video tapes, but 231 also embedded in compressed formats like MPEG. This field is 232 independent of the ``timestamp`` and ``sequence`` fields. 233 * - __u32 234 - ``sequence`` 235 - Set by the driver, counting the frames (not fields!) in sequence. 236 This field is set for both input and output devices. 237 * - :cspan:`2` 238 239 In :c:type:`V4L2_FIELD_ALTERNATE <v4l2_field>` mode the top and 240 bottom field have the same sequence number. The count starts at 241 zero and includes dropped or repeated frames. A dropped frame was 242 received by an input device but could not be stored due to lack of 243 free buffer space. A repeated frame was displayed again by an 244 output device because the application did not pass new data in 245 time. 246 247 .. note:: 248 249 This may count the frames received e.g. over USB, without 250 taking into account the frames dropped by the remote hardware due 251 to limited compression throughput or bus bandwidth. These devices 252 identify by not enumerating any video standards, see 253 :ref:`standard`. 254 255 * - __u32 256 - ``memory`` 257 - This field must be set by applications and/or drivers in 258 accordance with the selected I/O method. See :c:type:`v4l2_memory` 259 * - union { 260 - ``m`` 261 * - __u32 262 - ``offset`` 263 - For the single-planar API and when ``memory`` is 264 ``V4L2_MEMORY_MMAP`` this is the offset of the buffer from the 265 start of the device memory. The value is returned by the driver 266 and apart of serving as parameter to the 267 :ref:`mmap() <func-mmap>` function not useful for applications. 268 See :ref:`mmap` for details 269 * - unsigned long 270 - ``userptr`` 271 - For the single-planar API and when ``memory`` is 272 ``V4L2_MEMORY_USERPTR`` this is a pointer to the buffer (casted to 273 unsigned long type) in virtual memory, set by the application. See 274 :ref:`userp` for details. 275 * - struct v4l2_plane 276 - ``*planes`` 277 - When using the multi-planar API, contains a userspace pointer to 278 an array of struct :c:type:`v4l2_plane`. The size of 279 the array should be put in the ``length`` field of this 280 struct :c:type:`v4l2_buffer` structure. 281 * - int 282 - ``fd`` 283 - For the single-plane API and when ``memory`` is 284 ``V4L2_MEMORY_DMABUF`` this is the file descriptor associated with 285 a DMABUF buffer. 286 * - } 287 - 288 * - __u32 289 - ``length`` 290 - Size of the buffer (not the payload) in bytes for the 291 single-planar API. This is set by the driver based on the calls to 292 :ref:`VIDIOC_REQBUFS` and/or 293 :ref:`VIDIOC_CREATE_BUFS`. For the 294 multi-planar API the application sets this to the number of 295 elements in the ``planes`` array. The driver will fill in the 296 actual number of valid elements in that array. 297 * - __u32 298 - ``reserved2`` 299 - A place holder for future extensions. Drivers and applications 300 must set this to 0. 301 * - __u32 302 - ``request_fd`` 303 - The file descriptor of the request to queue the buffer to. If the flag 304 ``V4L2_BUF_FLAG_REQUEST_FD`` is set, then the buffer will be 305 queued to this request. If the flag is not set, then this field will 306 be ignored. 307 308 The ``V4L2_BUF_FLAG_REQUEST_FD`` flag and this field are only used by 309 :ref:`ioctl VIDIOC_QBUF <VIDIOC_QBUF>` and ignored by other ioctls that 310 take a :c:type:`v4l2_buffer` as argument. 311 312 Applications should not set ``V4L2_BUF_FLAG_REQUEST_FD`` for any ioctls 313 other than :ref:`VIDIOC_QBUF <VIDIOC_QBUF>`. 314 315 If the device does not support requests, then ``EBADR`` will be returned. 316 If requests are supported but an invalid request file descriptor is 317 given, then ``EINVAL`` will be returned. 318 319 320 321.. c:type:: v4l2_plane 322 323struct v4l2_plane 324================= 325 326.. tabularcolumns:: |p{3.5cm}|p{3.5cm}|p{3.5cm}|p{7.0cm}| 327 328.. cssclass:: longtable 329 330.. flat-table:: 331 :header-rows: 0 332 :stub-columns: 0 333 :widths: 1 1 2 334 335 * - __u32 336 - ``bytesused`` 337 - The number of bytes occupied by data in the plane (its payload). 338 Drivers must set this field when ``type`` refers to a capture 339 stream, applications when it refers to an output stream. If the 340 application sets this to 0 for an output stream, then 341 ``bytesused`` will be set to the size of the plane (see the 342 ``length`` field of this struct) by the driver. 343 344 .. note:: 345 346 Note that the actual image data starts at ``data_offset`` 347 which may not be 0. 348 * - __u32 349 - ``length`` 350 - Size in bytes of the plane (not its payload). This is set by the 351 driver based on the calls to 352 :ref:`VIDIOC_REQBUFS` and/or 353 :ref:`VIDIOC_CREATE_BUFS`. 354 * - union { 355 - ``m`` 356 * - __u32 357 - ``mem_offset`` 358 - When the memory type in the containing struct 359 :c:type:`v4l2_buffer` is ``V4L2_MEMORY_MMAP``, this 360 is the value that should be passed to :ref:`mmap() <func-mmap>`, 361 similar to the ``offset`` field in struct 362 :c:type:`v4l2_buffer`. 363 * - unsigned long 364 - ``userptr`` 365 - When the memory type in the containing struct 366 :c:type:`v4l2_buffer` is ``V4L2_MEMORY_USERPTR``, 367 this is a userspace pointer to the memory allocated for this plane 368 by an application. 369 * - int 370 - ``fd`` 371 - When the memory type in the containing struct 372 :c:type:`v4l2_buffer` is ``V4L2_MEMORY_DMABUF``, 373 this is a file descriptor associated with a DMABUF buffer, similar 374 to the ``fd`` field in struct :c:type:`v4l2_buffer`. 375 * - } 376 - 377 * - __u32 378 - ``data_offset`` 379 - Offset in bytes to video data in the plane. Drivers must set this 380 field when ``type`` refers to a capture stream, applications when 381 it refers to an output stream. 382 383 .. note:: 384 385 That data_offset is included in ``bytesused``. So the 386 size of the image in the plane is ``bytesused``-``data_offset`` 387 at offset ``data_offset`` from the start of the plane. 388 * - __u32 389 - ``reserved[11]`` 390 - Reserved for future use. Should be zeroed by drivers and 391 applications. 392 393 394 395.. c:type:: v4l2_buf_type 396 397enum v4l2_buf_type 398================== 399 400.. cssclass:: longtable 401 402.. tabularcolumns:: |p{7.8cm}|p{0.6cm}|p{9.1cm}| 403 404.. flat-table:: 405 :header-rows: 0 406 :stub-columns: 0 407 :widths: 4 1 9 408 409 * - ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` 410 - 1 411 - Buffer of a single-planar video capture stream, see 412 :ref:`capture`. 413 * - ``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` 414 - 9 415 - Buffer of a multi-planar video capture stream, see 416 :ref:`capture`. 417 * - ``V4L2_BUF_TYPE_VIDEO_OUTPUT`` 418 - 2 419 - Buffer of a single-planar video output stream, see 420 :ref:`output`. 421 * - ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE`` 422 - 10 423 - Buffer of a multi-planar video output stream, see :ref:`output`. 424 * - ``V4L2_BUF_TYPE_VIDEO_OVERLAY`` 425 - 3 426 - Buffer for video overlay, see :ref:`overlay`. 427 * - ``V4L2_BUF_TYPE_VBI_CAPTURE`` 428 - 4 429 - Buffer of a raw VBI capture stream, see :ref:`raw-vbi`. 430 * - ``V4L2_BUF_TYPE_VBI_OUTPUT`` 431 - 5 432 - Buffer of a raw VBI output stream, see :ref:`raw-vbi`. 433 * - ``V4L2_BUF_TYPE_SLICED_VBI_CAPTURE`` 434 - 6 435 - Buffer of a sliced VBI capture stream, see :ref:`sliced`. 436 * - ``V4L2_BUF_TYPE_SLICED_VBI_OUTPUT`` 437 - 7 438 - Buffer of a sliced VBI output stream, see :ref:`sliced`. 439 * - ``V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY`` 440 - 8 441 - Buffer for video output overlay (OSD), see :ref:`osd`. 442 * - ``V4L2_BUF_TYPE_SDR_CAPTURE`` 443 - 11 444 - Buffer for Software Defined Radio (SDR) capture stream, see 445 :ref:`sdr`. 446 * - ``V4L2_BUF_TYPE_SDR_OUTPUT`` 447 - 12 448 - Buffer for Software Defined Radio (SDR) output stream, see 449 :ref:`sdr`. 450 * - ``V4L2_BUF_TYPE_META_CAPTURE`` 451 - 13 452 - Buffer for metadata capture, see :ref:`metadata`. 453 * - ``V4L2_BUF_TYPE_META_OUTPUT`` 454 - 14 455 - Buffer for metadata output, see :ref:`metadata`. 456 457 458 459.. _buffer-flags: 460 461Buffer Flags 462============ 463 464.. raw:: latex 465 466 \small 467 468.. tabularcolumns:: |p{7.0cm}|p{2.1cm}|p{8.4cm}| 469 470.. cssclass:: longtable 471 472.. flat-table:: 473 :header-rows: 0 474 :stub-columns: 0 475 :widths: 3 1 4 476 477 * .. _`V4L2-BUF-FLAG-MAPPED`: 478 479 - ``V4L2_BUF_FLAG_MAPPED`` 480 - 0x00000001 481 - The buffer resides in device memory and has been mapped into the 482 application's address space, see :ref:`mmap` for details. 483 Drivers set or clear this flag when the 484 :ref:`VIDIOC_QUERYBUF`, 485 :ref:`VIDIOC_QBUF` or 486 :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl is called. Set by the 487 driver. 488 * .. _`V4L2-BUF-FLAG-QUEUED`: 489 490 - ``V4L2_BUF_FLAG_QUEUED`` 491 - 0x00000002 492 - Internally drivers maintain two buffer queues, an incoming and 493 outgoing queue. When this flag is set, the buffer is currently on 494 the incoming queue. It automatically moves to the outgoing queue 495 after the buffer has been filled (capture devices) or displayed 496 (output devices). Drivers set or clear this flag when the 497 ``VIDIOC_QUERYBUF`` ioctl is called. After (successful) calling 498 the ``VIDIOC_QBUF``\ ioctl it is always set and after 499 ``VIDIOC_DQBUF`` always cleared. 500 * .. _`V4L2-BUF-FLAG-DONE`: 501 502 - ``V4L2_BUF_FLAG_DONE`` 503 - 0x00000004 504 - When this flag is set, the buffer is currently on the outgoing 505 queue, ready to be dequeued from the driver. Drivers set or clear 506 this flag when the ``VIDIOC_QUERYBUF`` ioctl is called. After 507 calling the ``VIDIOC_QBUF`` or ``VIDIOC_DQBUF`` it is always 508 cleared. Of course a buffer cannot be on both queues at the same 509 time, the ``V4L2_BUF_FLAG_QUEUED`` and ``V4L2_BUF_FLAG_DONE`` flag 510 are mutually exclusive. They can be both cleared however, then the 511 buffer is in "dequeued" state, in the application domain so to 512 say. 513 * .. _`V4L2-BUF-FLAG-ERROR`: 514 515 - ``V4L2_BUF_FLAG_ERROR`` 516 - 0x00000040 517 - When this flag is set, the buffer has been dequeued successfully, 518 although the data might have been corrupted. This is recoverable, 519 streaming may continue as normal and the buffer may be reused 520 normally. Drivers set this flag when the ``VIDIOC_DQBUF`` ioctl is 521 called. 522 * .. _`V4L2-BUF-FLAG-IN-REQUEST`: 523 524 - ``V4L2_BUF_FLAG_IN_REQUEST`` 525 - 0x00000080 526 - This buffer is part of a request that hasn't been queued yet. 527 * .. _`V4L2-BUF-FLAG-KEYFRAME`: 528 529 - ``V4L2_BUF_FLAG_KEYFRAME`` 530 - 0x00000008 531 - Drivers set or clear this flag when calling the ``VIDIOC_DQBUF`` 532 ioctl. It may be set by video capture devices when the buffer 533 contains a compressed image which is a key frame (or field), i. e. 534 can be decompressed on its own. Also known as an I-frame. 535 Applications can set this bit when ``type`` refers to an output 536 stream. 537 * .. _`V4L2-BUF-FLAG-PFRAME`: 538 539 - ``V4L2_BUF_FLAG_PFRAME`` 540 - 0x00000010 541 - Similar to ``V4L2_BUF_FLAG_KEYFRAME`` this flags predicted frames 542 or fields which contain only differences to a previous key frame. 543 Applications can set this bit when ``type`` refers to an output 544 stream. 545 * .. _`V4L2-BUF-FLAG-BFRAME`: 546 547 - ``V4L2_BUF_FLAG_BFRAME`` 548 - 0x00000020 549 - Similar to ``V4L2_BUF_FLAG_KEYFRAME`` this flags a bi-directional 550 predicted frame or field which contains only the differences 551 between the current frame and both the preceding and following key 552 frames to specify its content. Applications can set this bit when 553 ``type`` refers to an output stream. 554 * .. _`V4L2-BUF-FLAG-TIMECODE`: 555 556 - ``V4L2_BUF_FLAG_TIMECODE`` 557 - 0x00000100 558 - The ``timecode`` field is valid. Drivers set or clear this flag 559 when the ``VIDIOC_DQBUF`` ioctl is called. Applications can set 560 this bit and the corresponding ``timecode`` structure when 561 ``type`` refers to an output stream. 562 * .. _`V4L2-BUF-FLAG-PREPARED`: 563 564 - ``V4L2_BUF_FLAG_PREPARED`` 565 - 0x00000400 566 - The buffer has been prepared for I/O and can be queued by the 567 application. Drivers set or clear this flag when the 568 :ref:`VIDIOC_QUERYBUF`, 569 :ref:`VIDIOC_PREPARE_BUF <VIDIOC_QBUF>`, 570 :ref:`VIDIOC_QBUF` or 571 :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl is called. 572 * .. _`V4L2-BUF-FLAG-NO-CACHE-INVALIDATE`: 573 574 - ``V4L2_BUF_FLAG_NO_CACHE_INVALIDATE`` 575 - 0x00000800 576 - Caches do not have to be invalidated for this buffer. Typically 577 applications shall use this flag if the data captured in the 578 buffer is not going to be touched by the CPU, instead the buffer 579 will, probably, be passed on to a DMA-capable hardware unit for 580 further processing or output. 581 * .. _`V4L2-BUF-FLAG-NO-CACHE-CLEAN`: 582 583 - ``V4L2_BUF_FLAG_NO_CACHE_CLEAN`` 584 - 0x00001000 585 - Caches do not have to be cleaned for this buffer. Typically 586 applications shall use this flag for output buffers if the data in 587 this buffer has not been created by the CPU but by some 588 DMA-capable unit, in which case caches have not been used. 589 * .. _`V4L2-BUF-FLAG-M2M-HOLD-CAPTURE-BUF`: 590 591 - ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` 592 - 0x00000200 593 - Only valid if ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` is 594 set. It is typically used with stateless decoders where multiple 595 output buffers each decode to a slice of the decoded frame. 596 Applications can set this flag when queueing the output buffer 597 to prevent the driver from dequeueing the capture buffer after 598 the output buffer has been decoded (i.e. the capture buffer is 599 'held'). If the timestamp of this output buffer differs from that 600 of the previous output buffer, then that indicates the start of a 601 new frame and the previously held capture buffer is dequeued. 602 * .. _`V4L2-BUF-FLAG-LAST`: 603 604 - ``V4L2_BUF_FLAG_LAST`` 605 - 0x00100000 606 - Last buffer produced by the hardware. mem2mem codec drivers set 607 this flag on the capture queue for the last buffer when the 608 :ref:`VIDIOC_QUERYBUF` or 609 :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl is called. Due to 610 hardware limitations, the last buffer may be empty. In this case 611 the driver will set the ``bytesused`` field to 0, regardless of 612 the format. Any Any subsequent call to the 613 :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore, 614 but return an ``EPIPE`` error code. 615 * .. _`V4L2-BUF-FLAG-REQUEST-FD`: 616 617 - ``V4L2_BUF_FLAG_REQUEST_FD`` 618 - 0x00800000 619 - The ``request_fd`` field contains a valid file descriptor. 620 * .. _`V4L2-BUF-FLAG-TIMESTAMP-MASK`: 621 622 - ``V4L2_BUF_FLAG_TIMESTAMP_MASK`` 623 - 0x0000e000 624 - Mask for timestamp types below. To test the timestamp type, mask 625 out bits not belonging to timestamp type by performing a logical 626 and operation with buffer flags and timestamp mask. 627 * .. _`V4L2-BUF-FLAG-TIMESTAMP-UNKNOWN`: 628 629 - ``V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN`` 630 - 0x00000000 631 - Unknown timestamp type. This type is used by drivers before Linux 632 3.9 and may be either monotonic (see below) or realtime (wall 633 clock). Monotonic clock has been favoured in embedded systems 634 whereas most of the drivers use the realtime clock. Either kinds 635 of timestamps are available in user space via 636 :c:func:`clock_gettime` using clock IDs ``CLOCK_MONOTONIC`` 637 and ``CLOCK_REALTIME``, respectively. 638 * .. _`V4L2-BUF-FLAG-TIMESTAMP-MONOTONIC`: 639 640 - ``V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC`` 641 - 0x00002000 642 - The buffer timestamp has been taken from the ``CLOCK_MONOTONIC`` 643 clock. To access the same clock outside V4L2, use 644 :c:func:`clock_gettime`. 645 * .. _`V4L2-BUF-FLAG-TIMESTAMP-COPY`: 646 647 - ``V4L2_BUF_FLAG_TIMESTAMP_COPY`` 648 - 0x00004000 649 - The CAPTURE buffer timestamp has been taken from the corresponding 650 OUTPUT buffer. This flag applies only to mem2mem devices. 651 * .. _`V4L2-BUF-FLAG-TSTAMP-SRC-MASK`: 652 653 - ``V4L2_BUF_FLAG_TSTAMP_SRC_MASK`` 654 - 0x00070000 655 - Mask for timestamp sources below. The timestamp source defines the 656 point of time the timestamp is taken in relation to the frame. 657 Logical 'and' operation between the ``flags`` field and 658 ``V4L2_BUF_FLAG_TSTAMP_SRC_MASK`` produces the value of the 659 timestamp source. Applications must set the timestamp source when 660 ``type`` refers to an output stream and 661 ``V4L2_BUF_FLAG_TIMESTAMP_COPY`` is set. 662 * .. _`V4L2-BUF-FLAG-TSTAMP-SRC-EOF`: 663 664 - ``V4L2_BUF_FLAG_TSTAMP_SRC_EOF`` 665 - 0x00000000 666 - End Of Frame. The buffer timestamp has been taken when the last 667 pixel of the frame has been received or the last pixel of the 668 frame has been transmitted. In practice, software generated 669 timestamps will typically be read from the clock a small amount of 670 time after the last pixel has been received or transmitten, 671 depending on the system and other activity in it. 672 * .. _`V4L2-BUF-FLAG-TSTAMP-SRC-SOE`: 673 674 - ``V4L2_BUF_FLAG_TSTAMP_SRC_SOE`` 675 - 0x00010000 676 - Start Of Exposure. The buffer timestamp has been taken when the 677 exposure of the frame has begun. This is only valid for the 678 ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type. 679 680.. raw:: latex 681 682 \normalsize 683 684 685.. c:type:: v4l2_memory 686 687enum v4l2_memory 688================ 689 690.. tabularcolumns:: |p{5.0cm}|p{0.8cm}|p{11.7cm}| 691 692.. flat-table:: 693 :header-rows: 0 694 :stub-columns: 0 695 :widths: 3 1 4 696 697 * - ``V4L2_MEMORY_MMAP`` 698 - 1 699 - The buffer is used for :ref:`memory mapping <mmap>` I/O. 700 * - ``V4L2_MEMORY_USERPTR`` 701 - 2 702 - The buffer is used for :ref:`user pointer <userp>` I/O. 703 * - ``V4L2_MEMORY_OVERLAY`` 704 - 3 705 - [to do] 706 * - ``V4L2_MEMORY_DMABUF`` 707 - 4 708 - The buffer is used for :ref:`DMA shared buffer <dmabuf>` I/O. 709 710 711 712Timecodes 713========= 714 715The :c:type:`v4l2_buffer_timecode` structure is designed to hold a 716:ref:`smpte12m` or similar timecode. 717(struct :c:type:`timeval` timestamps are stored in the struct 718:c:type:`v4l2_buffer` ``timestamp`` field.) 719 720 721.. c:type:: v4l2_timecode 722 723struct v4l2_timecode 724-------------------- 725 726.. tabularcolumns:: |p{1.4cm}|p{2.8cm}|p{12.3cm}| 727 728.. flat-table:: 729 :header-rows: 0 730 :stub-columns: 0 731 :widths: 1 1 2 732 733 * - __u32 734 - ``type`` 735 - Frame rate the timecodes are based on, see :ref:`timecode-type`. 736 * - __u32 737 - ``flags`` 738 - Timecode flags, see :ref:`timecode-flags`. 739 * - __u8 740 - ``frames`` 741 - Frame count, 0 ... 23/24/29/49/59, depending on the type of 742 timecode. 743 * - __u8 744 - ``seconds`` 745 - Seconds count, 0 ... 59. This is a binary, not BCD number. 746 * - __u8 747 - ``minutes`` 748 - Minutes count, 0 ... 59. This is a binary, not BCD number. 749 * - __u8 750 - ``hours`` 751 - Hours count, 0 ... 29. This is a binary, not BCD number. 752 * - __u8 753 - ``userbits``\ [4] 754 - The "user group" bits from the timecode. 755 756 757 758.. _timecode-type: 759 760Timecode Types 761-------------- 762 763.. tabularcolumns:: |p{5.6cm}|p{0.8cm}|p{11.1cm}| 764 765.. flat-table:: 766 :header-rows: 0 767 :stub-columns: 0 768 :widths: 3 1 4 769 770 * - ``V4L2_TC_TYPE_24FPS`` 771 - 1 772 - 24 frames per second, i. e. film. 773 * - ``V4L2_TC_TYPE_25FPS`` 774 - 2 775 - 25 frames per second, i. e. PAL or SECAM video. 776 * - ``V4L2_TC_TYPE_30FPS`` 777 - 3 778 - 30 frames per second, i. e. NTSC video. 779 * - ``V4L2_TC_TYPE_50FPS`` 780 - 4 781 - 782 * - ``V4L2_TC_TYPE_60FPS`` 783 - 5 784 - 785 786 787 788.. _timecode-flags: 789 790Timecode Flags 791-------------- 792 793.. tabularcolumns:: |p{6.6cm}|p{1.4cm}|p{9.5cm}| 794 795.. flat-table:: 796 :header-rows: 0 797 :stub-columns: 0 798 :widths: 3 1 4 799 800 * - ``V4L2_TC_FLAG_DROPFRAME`` 801 - 0x0001 802 - Indicates "drop frame" semantics for counting frames in 29.97 fps 803 material. When set, frame numbers 0 and 1 at the start of each 804 minute, except minutes 0, 10, 20, 30, 40, 50 are omitted from the 805 count. 806 * - ``V4L2_TC_FLAG_COLORFRAME`` 807 - 0x0002 808 - The "color frame" flag. 809 * - ``V4L2_TC_USERBITS_field`` 810 - 0x000C 811 - Field mask for the "binary group flags". 812 * - ``V4L2_TC_USERBITS_USERDEFINED`` 813 - 0x0000 814 - Unspecified format. 815 * - ``V4L2_TC_USERBITS_8BITCHARS`` 816 - 0x0008 817 - 8-bit ISO characters. 818