lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aLG19wzWBBECU6Cs@shepard>
Date: Fri, 29 Aug 2025 16:15:19 +0200
From: Paul Kocialkowski <paulk@...-base.io>
To: Nicolas Dufresne <nicolas.dufresne@...labora.com>
Cc: linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Hans Verkuil <hverkuil@...all.nl>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Dmitry Osipenko <digetx@...il.com>
Subject: Re: [PATCH v2 4/4] Documentation: media: Document
 V4L2_H264_DECODE_PARAM_FLAG_PFRAME/BFRAME

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

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ