IssueTracker

When decoding h264 stream on an ARM board from Texas Instruments with an AM62P SoC (https://www.ti.com/tool/PROCESSOR-SDK-AM62P), we see the following error:

DecodeComponent: Work with bitstreamId=105 not found, already abandoned?

This happens because v4l2_codec2 associates each input (OUTPUT) buffer with a single output (CAPTURE) buffer using bitstreamId.

bitstreamId is passed to the kernel via the timestamp. This is the recommended way according to the v4l2 spec:

To allow matching decoded CAPTURE buffers with OUTPUT buffers they originated from, the client can set the timestamp field of the v4l2_buffer struct when queuing an OUTPUT buffer. The CAPTURE buffer(s), which resulted from decoding that OUTPUT buffer will have their timestamp field set to the same value when dequeued

See: https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-decoder.html#decoding

By only allowing 1 output (CAPTURE) buffer per input (OUTPUT) buffer, the v4l2_codec2 HAL violates the following v4l2 spec:

The client must not assume any direct relationship between CAPTURE and OUTPUT buffers and any specific timing of buffers becoming available to dequeue. Specifically:

• a buffer queued to OUTPUT may result in no buffers being produced on CAPTURE (e.g. if it does not contain encoded data, or if only metadata syntax structures are present in it),
• a buffer queued to OUTPUT may result in more than one buffer produced on CAPTURE (if the encoded data contained more than one frame, or if returning a decoded frame allowed the decoder to return a frame that preceded it in decode, but succeeded it in the display order),
• a buffer queued to OUTPUT may result in a buffer being produced on CAPTURE later into decode process, and/or after processing further OUTPUT buffers, or be returned out of order, e.g. if display reordering is used,
• buffers may become available on the CAPTURE queue without additional buffers queued to OUTPUT (e.g. during drain or EOS), because of the OUTPUT buffers queued in the past whose decoding results are only available at later time, due to specifics of the decoding process. See: https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-decoder.html#decoding

Reworking the buffer tracking in v4l2_codec2 might be a difficult task. Are there any plans to address this?