Re: [RFC PATCH 00/11] VC8000E H.264 V4L2 Stateless Encoder

[Nicolas Dufresne <nicolas.dufresne@collabora.com>]

Hi Marco,


Le vendredi 02 mai 2025 à 17:05 +0200, Marco Felsch a écrit
> 
> [1] https://github.com/bootlin/linux/tree/hantro/h264-encoding-v5.11
> [2] https://gitlab.freedesktop.org/dude/gstreamer/-/tree/h264-stateless-encoder

Can you rebase against the upstream work:

https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5676

A lot of changes Michael made in your branch are already in the upstream MR
branch. An example, in the upstream version, the src pad (CAPTURE) is already
being set before the sink pad (OUTPUT).

I'd like to open the discussion about sizes, as I'm writing things down.
In your modification, you affirm that the encoder must ignore the size
set on the CAPTURE. At the moment I tend to disagree with this
interpretation and would like some feedback.

There is couple of different sizes we'll have to support:

1. Allocation sizes
2. coded size
3. display size

My believe is that we want to split the size in 1 and 2 since the padding
added to the allocated size should not affect the amount of bits that will
be compressed. We should be able to further pad frames without increasing
the compressed size.

For this, I wanted to mimic the stateless decoders, and define the coded
size, the one that occupy space in the bitstream and found in the sequence
headers to match the CATPURE size.

3. does not exists in stateless decoders, since it has no implication
in the decoding process. This one I'll leave open for now, since its
only needed if we have to generate some headers in the kernel. We have
had a lot of discussion toward that, and if so, I will pull in the
use of S_SELECTION.

regards,
Nicolas