planar-apis.rst 2.6 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162
  1. .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
  2. .. c:namespace:: V4L
  3. .. _planar-apis:
  4. *****************************
  5. Single- and multi-planar APIs
  6. *****************************
  7. Some devices require data for each input or output video frame to be
  8. placed in discontiguous memory buffers. In such cases, one video frame
  9. has to be addressed using more than one memory address, i.e. one pointer
  10. per "plane". A plane is a sub-buffer of the current frame. For examples
  11. of such formats see :ref:`pixfmt`.
  12. Initially, V4L2 API did not support multi-planar buffers and a set of
  13. extensions has been introduced to handle them. Those extensions
  14. constitute what is being referred to as the "multi-planar API".
  15. Some of the V4L2 API calls and structures are interpreted differently,
  16. depending on whether single- or multi-planar API is being used. An
  17. application can choose whether to use one or the other by passing a
  18. corresponding buffer type to its ioctl calls. Multi-planar versions of
  19. buffer types are suffixed with an ``_MPLANE`` string. For a list of
  20. available multi-planar buffer types see enum
  21. :c:type:`v4l2_buf_type`.
  22. Multi-planar formats
  23. ====================
  24. Multi-planar API introduces new multi-planar formats. Those formats use
  25. a separate set of FourCC codes. It is important to distinguish between
  26. the multi-planar API and a multi-planar format. Multi-planar API calls
  27. can handle all single-planar formats as well (as long as they are passed
  28. in multi-planar API structures), while the single-planar API cannot
  29. handle multi-planar formats.
  30. Calls that distinguish between single and multi-planar APIs
  31. ===========================================================
  32. :ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>`
  33. Two additional multi-planar capabilities are added. They can be set
  34. together with non-multi-planar ones for devices that handle both
  35. single- and multi-planar formats.
  36. :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`, :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`, :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`
  37. New structures for describing multi-planar formats are added: struct
  38. :c:type:`v4l2_pix_format_mplane` and
  39. struct :c:type:`v4l2_plane_pix_format`.
  40. Drivers may define new multi-planar formats, which have distinct
  41. FourCC codes from the existing single-planar ones.
  42. :ref:`VIDIOC_QBUF <VIDIOC_QBUF>`, :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>`, :ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>`
  43. A new struct :c:type:`v4l2_plane` structure for
  44. describing planes is added. Arrays of this structure are passed in
  45. the new ``m.planes`` field of struct
  46. :c:type:`v4l2_buffer`.
  47. :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>`
  48. Will allocate multi-planar buffers as requested.