Le dimanche 24 août 2025 à 20:07 +0200, Paul Kocialkowski a écrit :
> These flags are meant for a very specific use-case, add a mention of it.
> 
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> ---
>  .../userspace-api/media/v4l/ext-ctrls-codec-stateless.rst | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
> index 0da635691fdc..de1e3873385c 100644
> --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
> +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
> @@ -618,10 +618,14 @@ Stateless Codec Control ID
>        -
>      * - ``V4L2_H264_DECODE_PARAM_FLAG_PFRAME``
>        - 0x00000008
> -      -
> +      - All submitted slices for the frame are P slices. This is a compability
> +        flag required for decoders that only support decoding such frames, but
> +        should not be required for slice-based decoders.

Seems to match the comment in Tegra driver, and related to a hardware
limitation. Shall we also recommend not to use this unless similar limitation
exists ?

Note that mix of P and I, or, B and I, should still work on Tegra, its mixing P
and B that will fail since one of the reference list will be missing. At least,
this is my understanding.

Nicolas

>      * - ``V4L2_H264_DECODE_PARAM_FLAG_BFRAME``
>        - 0x00000010
> -      -
> +      - All submitted slices for the frame are B slices. This is a compability
> +        flag required for decoders that only support decoding such frames, but
> +        should not be required for slice-based decoders.
>  
>  .. raw:: latex
>