Pawel Osciak | 53b5d57 | 2011-01-07 01:41:33 -0300 | [diff] [blame^] | 1 | <section id="planar-apis"> |
| 2 | <title>Single- and multi-planar APIs</title> |
| 3 | |
| 4 | <para>Some devices require data for each input or output video frame |
| 5 | to be placed in discontiguous memory buffers. In such cases one |
| 6 | video frame has to be addressed using more than one memory address, i.e. one |
| 7 | pointer per "plane". A plane is a sub-buffer of current frame. For examples |
| 8 | of such formats see <xref linkend="pixfmt" />.</para> |
| 9 | |
| 10 | <para>Initially, V4L2 API did not support multi-planar buffers and a set of |
| 11 | extensions has been introduced to handle them. Those extensions constitute |
| 12 | what is being referred to as the "multi-planar API".</para> |
| 13 | |
| 14 | <para>Some of the V4L2 API calls and structures are interpreted differently, |
| 15 | depending on whether single- or multi-planar API is being used. An application |
| 16 | can choose whether to use one or the other by passing a corresponding buffer |
| 17 | type to its ioctl calls. Multi-planar versions of buffer types are suffixed with |
| 18 | an `_MPLANE' string. For a list of available multi-planar buffer types |
| 19 | see &v4l2-buf-type;. |
| 20 | </para> |
| 21 | |
| 22 | <section> |
| 23 | <title>Multi-planar formats</title> |
| 24 | <para>Multi-planar API introduces new multi-planar formats. Those formats |
| 25 | use 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 can |
| 27 | handle all single-planar formats as well, while the single-planar API cannot |
| 28 | handle multi-planar formats. Applications do not have to switch between APIs |
| 29 | when handling both single- and multi-planar devices and should use the |
| 30 | multi-planar API version for both single- and multi-planar formats. |
| 31 | Drivers that do not support multi-planar API can still be handled with it, |
| 32 | utilizing a compatibility layer built into standard V4L2 ioctl handling. |
| 33 | </para> |
| 34 | </section> |
| 35 | |
| 36 | <section> |
| 37 | <title>Single and multi-planar API compatibility layer</title> |
| 38 | <para>In most cases<footnote><para>The compatibility layer does not cover |
| 39 | drivers that do not use video_ioctl2() call.</para></footnote>, applications |
| 40 | can use the multi-planar API with older drivers that support |
| 41 | only its single-planar version and vice versa. Appropriate conversion is |
| 42 | done seamlessly for both applications and drivers in the V4L2 core. The |
| 43 | general rule of thumb is: as long as an application uses formats that |
| 44 | a driver supports, it can use either API (although use of multi-planar |
| 45 | formats is only possible with the multi-planar API). The list of formats |
| 46 | supported by a driver can be obtained using the &VIDIOC-ENUM-FMT; call. |
| 47 | It is possible, but discouraged, for a driver or an application to support |
| 48 | and use both versions of the API.</para> |
| 49 | </section> |
| 50 | |
| 51 | <section> |
| 52 | <title>Calls that distinguish between single and multi-planar APIs</title> |
| 53 | <variablelist> |
| 54 | <varlistentry> |
| 55 | <term>&VIDIOC-QUERYCAP;</term> |
| 56 | <listitem>Two additional multi-planar capabilities are added. They can |
| 57 | be set together with non-multi-planar ones for devices that handle |
| 58 | both single- and multi-planar formats.</listitem> |
| 59 | </varlistentry> |
| 60 | <varlistentry> |
| 61 | <term>&VIDIOC-G-FMT;, &VIDIOC-S-FMT;, &VIDIOC-TRY-FMT;</term> |
| 62 | <listitem>New structures for describing multi-planar formats are added: |
| 63 | &v4l2-pix-format-mplane; and &v4l2-plane-pix-format;. Drivers may |
| 64 | define new multi-planar formats, which have distinct FourCC codes from |
| 65 | the existing single-planar ones. |
| 66 | </listitem> |
| 67 | </varlistentry> |
| 68 | <varlistentry> |
| 69 | <term>&VIDIOC-QBUF;, &VIDIOC-DQBUF;, &VIDIOC-QUERYBUF;</term> |
| 70 | <listitem>A new &v4l2-plane; structure for describing planes is added. |
| 71 | Arrays of this structure are passed in the new |
| 72 | <structfield>m.planes</structfield> field of &v4l2-buffer;. |
| 73 | </listitem> |
| 74 | </varlistentry> |
| 75 | <varlistentry> |
| 76 | <term>&VIDIOC-REQBUFS;</term> |
| 77 | <listitem>Will allocate multi-planar buffers as requested.</listitem> |
| 78 | </varlistentry> |
| 79 | </variablelist> |
| 80 | </section> |
| 81 | </section> |