summaryrefslogtreecommitdiffstats
path: root/Documentation/linux_tv/media/v4l/planar-apis.rst
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/linux_tv/media/v4l/planar-apis.rst')
-rw-r--r--Documentation/linux_tv/media/v4l/planar-apis.rst74
1 files changed, 74 insertions, 0 deletions
diff --git a/Documentation/linux_tv/media/v4l/planar-apis.rst b/Documentation/linux_tv/media/v4l/planar-apis.rst
new file mode 100644
index 0000000..4c01adc
--- /dev/null
+++ b/Documentation/linux_tv/media/v4l/planar-apis.rst
@@ -0,0 +1,74 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _planar-apis:
+
+*****************************
+Single- and multi-planar APIs
+*****************************
+
+Some devices require data for each input or output video frame to be
+placed in discontiguous memory buffers. In such cases, one video frame
+has to be addressed using more than one memory address, i.e. one pointer
+per "plane". A plane is a sub-buffer of the current frame. For examples
+of such formats see :ref:`pixfmt`.
+
+Initially, V4L2 API did not support multi-planar buffers and a set of
+extensions has been introduced to handle them. Those extensions
+constitute what is being referred to as the "multi-planar API".
+
+Some of the V4L2 API calls and structures are interpreted differently,
+depending on whether single- or multi-planar API is being used. An
+application can choose whether to use one or the other by passing a
+corresponding buffer type to its ioctl calls. Multi-planar versions of
+buffer types are suffixed with an `_MPLANE' string. For a list of
+available multi-planar buffer types see enum
+:ref:`v4l2_buf_type <v4l2-buf-type>`.
+
+
+Multi-planar formats
+====================
+
+Multi-planar API introduces new multi-planar formats. Those formats use
+a separate set of FourCC codes. It is important to distinguish between
+the multi-planar API and a multi-planar format. Multi-planar API calls
+can handle all single-planar formats as well (as long as they are passed
+in multi-planar API structures), while the single-planar API cannot
+handle multi-planar formats.
+
+
+Calls that distinguish between single and multi-planar APIs
+===========================================================
+
+:ref:`VIDIOC_QUERYCAP <vidioc-querycap>`
+ Two additional multi-planar capabilities are added. They can be set
+ together with non-multi-planar ones for devices that handle both
+ single- and multi-planar formats.
+
+:ref:`VIDIOC_G_FMT <vidioc-g-fmt>`,
+:ref:`VIDIOC_S_FMT <vidioc-g-fmt>`,
+:ref:`VIDIOC_TRY_FMT <vidioc-g-fmt>`
+ New structures for describing multi-planar formats are added: struct
+ :ref:`v4l2_pix_format_mplane <v4l2-pix-format-mplane>` and
+ struct :ref:`v4l2_plane_pix_format <v4l2-plane-pix-format>`.
+ Drivers may define new multi-planar formats, which have distinct
+ FourCC codes from the existing single-planar ones.
+
+:ref:`VIDIOC_QBUF <vidioc-qbuf>`,
+:ref:`VIDIOC_DQBUF <vidioc-qbuf>`,
+:ref:`VIDIOC_QUERYBUF <vidioc-querybuf>`
+ A new struct :ref:`v4l2_plane <v4l2-plane>` structure for
+ describing planes is added. Arrays of this structure are passed in
+ the new ``m.planes`` field of struct
+ :ref:`v4l2_buffer <v4l2-buffer>`.
+
+:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>`
+ Will allocate multi-planar buffers as requested.
+
+
+.. ------------------------------------------------------------------------------
+.. This file was automatically converted from DocBook-XML with the dbxml
+.. library (https://github.com/return42/sphkerneldoc). The origin XML comes
+.. from the linux kernel, refer to:
+..
+.. * https://github.com/torvalds/linux/tree/master/Documentation/DocBook
+.. ------------------------------------------------------------------------------
OpenPOWER on IntegriCloud