Re: [PATCH v2 4/4] Documentation: media: Document V4L2_H264_DECODE_PARAM_FLAG_PFRAME/BFRAME

[Paul Kocialkowski <paulk@sys-base.io>]

[-- Attachment #1: Type: text/plain, Size: 3654 bytes --]

Hi,

+ Adding Dmitry in the loop (whom I forgot, sorry).

Dmitry, we're discussing the precise meaning of the Tegra VDE H.264 decode
flags that indicate PFRAME/BFRAME.

On Thu 28 Aug 25, 16:42, Nicolas Dufresne wrote:
> 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 ?

I think the flag should only be allowed for frame-based decode mode and indeed
it would be good to say that drivers should only check this flag if they have
such limitations.

Userspace on the other hand cannot really know if it will be used or not so it
should set the flags when applicable.

> 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.

Well the comment in the driver mandates that "frame consists of the same type
slices" and "decoding of a non-uniform frames isn't supported by hardware".

But looking at the code these statements seem exaggerated and I concur to your
understanding that at least mixing I and P should work, since it only sets up
the L0 reference list. There's an explicit hardware flag for "B frames" that
could have a more restrictive meaning. Maybe it also allows I frames and/or
P frames, maybe not.

So perhaps we could relax the definitions to an indication that the L0/L1
reference lists will be used by the frame slices, which implicitly allows mixing
different types of slices.

After all it is likely that decoders in that situation just really care about
having the required ref lists prepared and don't particularly need each
slice_type to be the same. After all they're still parsing the slice headers so
they do have all the slice-specific info.

Paul

> 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
> >  



-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]