Lines Matching +full:frame +full:- +full:buffer
1 .. SPDX-License-Identifier: GPL-2.0
6 Memory-to-memory Stateless Video Decoder Interface
10 between processed frames. This means that each frame is decoded independently
18 This section describes how user-space ("the client") is expected to communicate
24 Stateless decoders make use of the :ref:`media-request-api`. A stateless
30 frame may be the result of several decode requests (for instance, H.264 streams
31 with multiple slices per frame). Decoders that support such formats must also
45 codec-specific capability controls (such as H.264 profiles) to the set
55 formats may depend on the value of some codec-dependent controls.
110 frame buffer resolution for the decoded frames.
119 as per standard semantics; matching frame buffer format.
162 frame buffer resolution of the decoded stream; typically unchanged from
167 to obtain up-to-date information about the buffers size and layout.
222 8. Allocate requests (likely one per ``OUTPUT`` buffer) via
231 For each frame, the client is responsible for submitting at least one request to
235 configuration, as a buffer submitted to the ``OUTPUT`` queue. Typically, this
236 corresponds to one frame worth of encoded data, but some formats may allow (or
241 The amount of data and contents of the source ``OUTPUT`` buffer, as well as the
243 format and might be affected by codec-specific extended controls, as stated in
246 If there is a possibility that the decoded frame will require one or more
249 buffer. This will result in the (potentially partially) decoded ``CAPTURE``
250 buffer not being made available for dequeueing, and reused for the next decode
251 request if the timestamp of the next ``OUTPUT`` buffer has not changed.
253 A typical frame would thus be decoded using the following sequence:
255 1. Queue an ``OUTPUT`` buffer containing one unit of encoded bytestream data for
261 index of the buffer being queued.
264 type of the buffer.
267 number of bytes taken by the encoded data frame in the buffer.
272 to produce a fully decoded frame, then
279 must be set to a unique value per frame. This value will be propagated
280 into the decoded frame's buffer and can also be used to use this frame
282 frame, then the timestamps of all the ``OUTPUT`` buffers for a given
283 frame must be identical. If the timestamp changes, then the currently
284 held ``CAPTURE`` buffer will be made available for dequeuing and the
285 current request will work on a new ``CAPTURE`` buffer.
287 2. Set the codec-specific controls for the decoding request, using
300 array must contain all the codec-specific controls required to decode
301 a frame.
317 If the request is submitted without an ``OUTPUT`` buffer, or if some of the
319 :c:func:`MEDIA_REQUEST_IOC_QUEUE` will return ``-ENOENT``. If more than one
320 ``OUTPUT`` buffer is queued, then it will return ``-EINVAL``.
321 :c:func:`MEDIA_REQUEST_IOC_QUEUE` returning non-zero means that no
322 ``CAPTURE`` buffer will be produced for this request.
329 carrying the ``V4L2_BUF_FLAG_ERROR`` flag. If a decoded reference frame has an
334 Buffer management while decoding
337 buffer management: it only guarantees that dequeued ``CAPTURE`` buffers can be
339 encompasses using the buffer for compositing or display.
341 A dequeued capture buffer can also be used as the reference frame of another
342 buffer.
344 A frame is specified as reference by converting its timestamp into nanoseconds,
345 and storing it into the relevant member of a codec-dependent control structure.
347 conversion. The timestamp of a frame can be used to reference it as soon as all
350 A decoded buffer containing a reference frame must not be reused as a decoding
352 achieve this is to refrain from queueing a reference buffer until all the
355 order, then user-space can take advantage of this guarantee and queue a
356 reference buffer when the following conditions are met:
358 1. All the requests for frames affected by the reference frame have been
366 can e.g. close the DMABUF file descriptors of reference frame buffers if it
378 The client is then free to ignore any returned ``CAPTURE`` buffer that comes
379 from the pre-seek position.
394 1. If the last submitted request resulted in a ``CAPTURE`` buffer being
396 last frame is not available on the ``CAPTURE`` queue. In this case, a
398 dequeue the held ``CAPTURE`` buffer.
407 ``CAPTURE`` queue with a buffer count of zero.
417 If the last submitted request resulted in a ``CAPTURE`` buffer being
419 last frame is not available on the ``CAPTURE`` queue. In this case, a
421 dequeue the held ``CAPTURE`` buffer.