^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) .. _stateless_decoder:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) **************************************************
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) Memory-to-memory Stateless Video Decoder Interface
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) **************************************************
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) A stateless decoder is a decoder that works without retaining any kind of state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) between processed frames. This means that each frame is decoded independently
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) of any previous and future frames, and that the client is responsible for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) maintaining the decoding state and providing it to the decoder with each
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) decoding request. This is in contrast to the stateful video decoder interface,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) where the hardware and driver maintain the decoding state and all the client
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) has to do is to provide the raw encoded stream and dequeue decoded frames in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) display order.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) This section describes how user-space ("the client") is expected to communicate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) with stateless decoders in order to successfully decode an encoded stream.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) Compared to stateful codecs, the decoder/client sequence is simpler, but the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) cost of this simplicity is extra complexity in the client which is responsible
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) for maintaining a consistent decoding state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) Stateless decoders make use of the :ref:`media-request-api`. A stateless
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) decoder must expose the ``V4L2_BUF_CAP_SUPPORTS_REQUESTS`` capability on its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) ``OUTPUT`` queue when :c:func:`VIDIOC_REQBUFS` or :c:func:`VIDIOC_CREATE_BUFS`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) are invoked.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) Depending on the encoded formats supported by the decoder, a single decoded
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) frame may be the result of several decode requests (for instance, H.264 streams
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) with multiple slices per frame). Decoders that support such formats must also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) expose the ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` capability on their
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) ``OUTPUT`` queue.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) Querying capabilities
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) 1. To enumerate the set of coded formats supported by the decoder, the client
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) calls :c:func:`VIDIOC_ENUM_FMT` on the ``OUTPUT`` queue.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) * The driver must always return the full set of supported ``OUTPUT`` formats,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) irrespective of the format currently set on the ``CAPTURE`` queue.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) * Simultaneously, the driver must restrain the set of values returned by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) codec-specific capability controls (such as H.264 profiles) to the set
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) actually supported by the hardware.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) 2. To enumerate the set of supported raw formats, the client calls
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) :c:func:`VIDIOC_ENUM_FMT` on the ``CAPTURE`` queue.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) * The driver must return only the formats supported for the format currently
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) active on the ``OUTPUT`` queue.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) * Depending on the currently set ``OUTPUT`` format, the set of supported raw
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) formats may depend on the value of some codec-dependent controls.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) The client is responsible for making sure that these controls are set
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) before querying the ``CAPTURE`` queue. Failure to do so will result in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) default values for these controls being used, and a returned set of formats
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) that may not be usable for the media the client is trying to decode.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) 3. The client may use :c:func:`VIDIOC_ENUM_FRAMESIZES` to detect supported
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) resolutions for a given format, passing desired pixel format in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) :c:type:`v4l2_frmsizeenum`'s ``pixel_format``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) 4. Supported profiles and levels for the current ``OUTPUT`` format, if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) applicable, may be queried using their respective controls via
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) :c:func:`VIDIOC_QUERYCTRL`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) Initialization
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) 1. Set the coded format on the ``OUTPUT`` queue via :c:func:`VIDIOC_S_FMT`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) * **Required fields:**
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) ``type``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) ``pixelformat``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) a coded pixel format.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) ``width``, ``height``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) coded width and height parsed from the stream.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) other fields
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) follow standard semantics.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) .. note::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) Changing the ``OUTPUT`` format may change the currently set ``CAPTURE``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) format. The driver will derive a new ``CAPTURE`` format from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) ``OUTPUT`` format being set, including resolution, colorimetry
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) parameters, etc. If the client needs a specific ``CAPTURE`` format,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) it must adjust it afterwards.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) 2. Call :c:func:`VIDIOC_S_EXT_CTRLS` to set all the controls (parsed headers,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) etc.) required by the ``OUTPUT`` format to enumerate the ``CAPTURE`` formats.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) 3. Call :c:func:`VIDIOC_G_FMT` for ``CAPTURE`` queue to get the format for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) destination buffers parsed/decoded from the bytestream.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) * **Required fields:**
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) ``type``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) * **Returned fields:**
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) ``width``, ``height``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) frame buffer resolution for the decoded frames.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) ``pixelformat``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) pixel format for decoded frames.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) ``num_planes`` (for _MPLANE ``type`` only)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) number of planes for pixelformat.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) ``sizeimage``, ``bytesperline``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) as per standard semantics; matching frame buffer format.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) .. note::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) The value of ``pixelformat`` may be any pixel format supported for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) ``OUTPUT`` format, based on the hardware capabilities. It is suggested
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) that the driver chooses the preferred/optimal format for the current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) configuration. For example, a YUV format may be preferred over an RGB
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) format, if an additional conversion step would be required for RGB.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) 4. *[optional]* Enumerate ``CAPTURE`` formats via :c:func:`VIDIOC_ENUM_FMT` on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) the ``CAPTURE`` queue. The client may use this ioctl to discover which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) alternative raw formats are supported for the current ``OUTPUT`` format and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) select one of them via :c:func:`VIDIOC_S_FMT`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) .. note::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) The driver will return only formats supported for the currently selected
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) ``OUTPUT`` format and currently set controls, even if more formats may be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) supported by the decoder in general.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) For example, a decoder may support YUV and RGB formats for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) resolutions 1920x1088 and lower, but only YUV for higher resolutions (due
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) to hardware limitations). After setting a resolution of 1920x1088 or lower
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) as the ``OUTPUT`` format, :c:func:`VIDIOC_ENUM_FMT` may return a set of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) YUV and RGB pixel formats, but after setting a resolution higher than
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) 1920x1088, the driver will not return RGB pixel formats, since they are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) unsupported for this resolution.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) 5. *[optional]* Choose a different ``CAPTURE`` format than suggested via
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) :c:func:`VIDIOC_S_FMT` on ``CAPTURE`` queue. It is possible for the client to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) choose a different format than selected/suggested by the driver in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) :c:func:`VIDIOC_G_FMT`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) * **Required fields:**
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) ``type``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) ``pixelformat``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) a raw pixel format.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) ``width``, ``height``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) frame buffer resolution of the decoded stream; typically unchanged from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) what was returned with :c:func:`VIDIOC_G_FMT`, but it may be different
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) if the hardware supports composition and/or scaling.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) After performing this step, the client must perform step 3 again in order
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) to obtain up-to-date information about the buffers size and layout.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) 6. Allocate source (bytestream) buffers via :c:func:`VIDIOC_REQBUFS` on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) ``OUTPUT`` queue.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) * **Required fields:**
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) ``count``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) requested number of buffers to allocate; greater than zero.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) ``type``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) ``memory``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) follows standard semantics.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) * **Return fields:**
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) ``count``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) actual number of buffers allocated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) * If required, the driver will adjust ``count`` to be equal or bigger to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) minimum of required number of ``OUTPUT`` buffers for the given format and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) requested count. The client must check this value after the ioctl returns
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) to get the actual number of buffers allocated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) 7. Allocate destination (raw format) buffers via :c:func:`VIDIOC_REQBUFS` on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) ``CAPTURE`` queue.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) * **Required fields:**
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) ``count``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) requested number of buffers to allocate; greater than zero. The client
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) is responsible for deducing the minimum number of buffers required
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) for the stream to be properly decoded (taking e.g. reference frames
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) into account) and pass an equal or bigger number.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) ``type``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) ``memory``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) follows standard semantics. ``V4L2_MEMORY_USERPTR`` is not supported
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) for ``CAPTURE`` buffers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) * **Return fields:**
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) ``count``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) adjusted to allocated number of buffers, in case the codec requires
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) more buffers than requested.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) * The driver must adjust count to the minimum of required number of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) ``CAPTURE`` buffers for the current format, stream configuration and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) requested count. The client must check this value after the ioctl
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) returns to get the number of buffers allocated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) 8. Allocate requests (likely one per ``OUTPUT`` buffer) via
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) :c:func:`MEDIA_IOC_REQUEST_ALLOC` on the media device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) 9. Start streaming on both ``OUTPUT`` and ``CAPTURE`` queues via
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) :c:func:`VIDIOC_STREAMON`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) Decoding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) ========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) For each frame, the client is responsible for submitting at least one request to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) which the following is attached:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) * The amount of encoded data expected by the codec for its current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) configuration, as a buffer submitted to the ``OUTPUT`` queue. Typically, this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) corresponds to one frame worth of encoded data, but some formats may allow (or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) require) different amounts per unit.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) * All the metadata needed to decode the submitted encoded data, in the form of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) controls relevant to the format being decoded.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) The amount of data and contents of the source ``OUTPUT`` buffer, as well as the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) controls that must be set on the request, depend on the active coded pixel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) format and might be affected by codec-specific extended controls, as stated in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) documentation of each format.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) If there is a possibility that the decoded frame will require one or more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) decode requests after the current one in order to be produced, then the client
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) must set the ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag on the ``OUTPUT``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) buffer. This will result in the (potentially partially) decoded ``CAPTURE``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) buffer not being made available for dequeueing, and reused for the next decode
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) request if the timestamp of the next ``OUTPUT`` buffer has not changed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) A typical frame would thus be decoded using the following sequence:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) 1. Queue an ``OUTPUT`` buffer containing one unit of encoded bytestream data for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) the decoding request, using :c:func:`VIDIOC_QBUF`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) * **Required fields:**
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) ``index``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) index of the buffer being queued.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) ``type``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) type of the buffer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) ``bytesused``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) number of bytes taken by the encoded data frame in the buffer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) ``flags``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) the ``V4L2_BUF_FLAG_REQUEST_FD`` flag must be set. Additionally, if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) we are not sure that the current decode request is the last one needed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) to produce a fully decoded frame, then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` must also be set.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) ``request_fd``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) must be set to the file descriptor of the decoding request.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) ``timestamp``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) must be set to a unique value per frame. This value will be propagated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) into the decoded frame's buffer and can also be used to use this frame
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) as the reference of another. If using multiple decode requests per
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) frame, then the timestamps of all the ``OUTPUT`` buffers for a given
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) frame must be identical. If the timestamp changes, then the currently
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) held ``CAPTURE`` buffer will be made available for dequeuing and the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) current request will work on a new ``CAPTURE`` buffer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) 2. Set the codec-specific controls for the decoding request, using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) :c:func:`VIDIOC_S_EXT_CTRLS`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) * **Required fields:**
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) ``which``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) must be ``V4L2_CTRL_WHICH_REQUEST_VAL``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) ``request_fd``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) must be set to the file descriptor of the decoding request.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) other fields
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) other fields are set as usual when setting controls. The ``controls``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) array must contain all the codec-specific controls required to decode
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) a frame.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) .. note::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) It is possible to specify the controls in different invocations of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) :c:func:`VIDIOC_S_EXT_CTRLS`, or to overwrite a previously set control, as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) long as ``request_fd`` and ``which`` are properly set. The controls state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308) at the moment of request submission is the one that will be considered.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310) .. note::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312) The order in which steps 1 and 2 take place is interchangeable.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314) 3. Submit the request by invoking :c:func:`MEDIA_REQUEST_IOC_QUEUE` on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315) request FD.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) If the request is submitted without an ``OUTPUT`` buffer, or if some of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318) required controls are missing from the request, then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) :c:func:`MEDIA_REQUEST_IOC_QUEUE` will return ``-ENOENT``. If more than one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) ``OUTPUT`` buffer is queued, then it will return ``-EINVAL``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) :c:func:`MEDIA_REQUEST_IOC_QUEUE` returning non-zero means that no
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) ``CAPTURE`` buffer will be produced for this request.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324) ``CAPTURE`` buffers must not be part of the request, and are queued
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) independently. They are returned in decode order (i.e. the same order as coded
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326) frames were submitted to the ``OUTPUT`` queue).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) Runtime decoding errors are signaled by the dequeued ``CAPTURE`` buffers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329) carrying the ``V4L2_BUF_FLAG_ERROR`` flag. If a decoded reference frame has an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) error, then all following decoded frames that refer to it also have the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) ``V4L2_BUF_FLAG_ERROR`` flag set, although the decoder will still try to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) produce (likely corrupted) frames.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334) Buffer management while decoding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) ================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336) Contrary to stateful decoders, a stateless decoder does not perform any kind of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) buffer management: it only guarantees that dequeued ``CAPTURE`` buffers can be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338) used by the client for as long as they are not queued again. "Used" here
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) encompasses using the buffer for compositing or display.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) A dequeued capture buffer can also be used as the reference frame of another
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) buffer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344) A frame is specified as reference by converting its timestamp into nanoseconds,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) and storing it into the relevant member of a codec-dependent control structure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) The :c:func:`v4l2_timeval_to_ns` function must be used to perform that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) conversion. The timestamp of a frame can be used to reference it as soon as all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) its units of encoded data are successfully submitted to the ``OUTPUT`` queue.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) A decoded buffer containing a reference frame must not be reused as a decoding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) target until all the frames referencing it have been decoded. The safest way to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352) achieve this is to refrain from queueing a reference buffer until all the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353) decoded frames referencing it have been dequeued. However, if the driver can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) guarantee that buffers queued to the ``CAPTURE`` queue are processed in queued
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) order, then user-space can take advantage of this guarantee and queue a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356) reference buffer when the following conditions are met:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) 1. All the requests for frames affected by the reference frame have been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) queued, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) 2. A sufficient number of ``CAPTURE`` buffers to cover all the decoded
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) referencing frames have been queued.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) When queuing a decoding request, the driver will increase the reference count of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) all the resources associated with reference frames. This means that the client
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366) can e.g. close the DMABUF file descriptors of reference frame buffers if it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) won't need them afterwards.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369) Seeking
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) =======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371) In order to seek, the client just needs to submit requests using input buffers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) corresponding to the new stream position. It must however be aware that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373) resolution may have changed and follow the dynamic resolution change sequence in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374) that case. Also depending on the codec used, picture parameters (e.g. SPS/PPS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375) for H.264) may have changed and the client is responsible for making sure that a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376) valid state is sent to the decoder.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) The client is then free to ignore any returned ``CAPTURE`` buffer that comes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379) from the pre-seek position.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381) Pausing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) =======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384) In order to pause, the client can just cease queuing buffers onto the ``OUTPUT``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) queue. Without source bytestream data, there is no data to process and the codec
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386) will remain idle.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) Dynamic resolution change
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) =========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391) If the client detects a resolution change in the stream, it will need to perform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392) the initialization sequence again with the new resolution:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) 1. If the last submitted request resulted in a ``CAPTURE`` buffer being
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) held by the use of the ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag, then the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) last frame is not available on the ``CAPTURE`` queue. In this case, a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) ``V4L2_DEC_CMD_FLUSH`` command shall be sent. This will make the driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) dequeue the held ``CAPTURE`` buffer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) 2. Wait until all submitted requests have completed and dequeue the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401) corresponding output buffers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403) 3. Call :c:func:`VIDIOC_STREAMOFF` on both the ``OUTPUT`` and ``CAPTURE``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404) queues.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406) 4. Free all ``CAPTURE`` buffers by calling :c:func:`VIDIOC_REQBUFS` on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407) ``CAPTURE`` queue with a buffer count of zero.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409) 5. Perform the initialization sequence again (minus the allocation of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) ``OUTPUT`` buffers), with the new resolution set on the ``OUTPUT`` queue.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) Note that due to resolution constraints, a different format may need to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412) picked on the ``CAPTURE`` queue.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414) Drain
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) =====
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) If the last submitted request resulted in a ``CAPTURE`` buffer being
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) held by the use of the ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag, then the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419) last frame is not available on the ``CAPTURE`` queue. In this case, a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) ``V4L2_DEC_CMD_FLUSH`` command shall be sent. This will make the driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421) dequeue the held ``CAPTURE`` buffer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423) After that, in order to drain the stream on a stateless decoder, the client
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424) just needs to wait until all the submitted requests are completed.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags