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: <19cdb1996557824554789dccc805014b0fa2deda.camel@collabora.com>
Date: Fri, 07 Nov 2025 08:41:41 -0500
From: Nicolas Dufresne <nicolas.dufresne@...labora.com>
To: Hans Verkuil <hverkuil+cisco@...nel.org>, Deepa Guthyappa Madivalara	
 <deepa.madivalara@....qualcomm.com>, Mauro Carvalho Chehab
 <mchehab@...nel.org>,  Vikash Garodia <vikash.garodia@....qualcomm.com>,
 Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>,  Abhinav Kumar
 <abhinav.kumar@...ux.dev>, Bryan O'Donoghue <bod@...nel.org>
Cc: linux-media@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-msm@...r.kernel.org, kernel test robot <lkp@...el.com>, Bryan
 O'Donoghue <bryan.odonoghue@...aro.org>
Subject: Re: [PATCH v4 1/5] media: uapi: videodev2: Add support for AV1
 stateful decoder

Le vendredi 07 novembre 2025 à 10:25 +0100, Hans Verkuil a écrit :
> On 03/11/2025 14:24, Deepa Guthyappa Madivalara wrote:
> > Introduce a new pixel format, V4L2_PIX_FMT_AV1, to the
> > Video4Linux2(V4L2) API. This format is intended for AV1
> > bitstreams in stateful decoding/encoding workflows.
> > The fourcc code 'AV10' is used to distinguish
> > this format from the existing V4L2_PIX_FMT_AV1_FRAME,
> > which is used for stateless AV1 decoder implementation.
> > 
> > Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
> > Reviewed-by: Nicolas Dufresne <nicolas.dufresne@...labora.com>
> > Signed-off-by: Deepa Guthyappa Madivalara <deepa.madivalara@....qualcomm.com>
> > ---
> >  Documentation/userspace-api/media/v4l/pixfmt-compressed.rst | 8 ++++++++
> >  include/uapi/linux/videodev2.h                              | 1 +
> >  2 files changed, 9 insertions(+)
> > 
> > diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
> > index c7efb0465db6480fe35be8557728c196e0e530f4..0c70410ffd4d58e0719d3cf13ad336c97b454ae9 100644
> > --- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
> > +++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
> > @@ -275,6 +275,14 @@ Compressed Formats
> >          of macroblocks to decode a full corresponding frame to the matching
> >          capture buffer.
> >  
> > +    * .. _V4L2-PIX-FMT-AV1:
> > +
> > +      - ``V4L2_PIX_FMT_AV1``
> > +      - 'AV01'
> > +      - AV1 compressed video frame. This format is adapted for implementing AV1
> > +        pipeline. The decoder implements stateful video decoder and expects one
> > +        Temporal Unit per buffer from OBU-stream or AnnexB.
> 
> OK, but the next patch says:
> 
> 		case V4L2_PIX_FMT_AV1:		descr = "AV1 OBU stream"; break;
> 
> And Nicolas said here:

Hmm, good catch, we had quite a bit of back and forth actually on the subject.
The discussion went toward that this is OBU Stream format, but it is conceivable
to enable Annex B support in the future using a control. That mandates that OBU
stream must always be supported for that format.

I'd drop the "or AnnexB". Then I'd try and harmonize how we write OBU stream, I
prefer without the -.

> 
> https://lore.kernel.org/linux-media/544147436308901fba85d6de48380c0c1eea7c67.camel@ndufresne.ca/
> 
> "Perhaps "AV1 OBU stream", so its clear its no Annex B ?"
> 
> So if this is just for OBU streams and not Annex B, then the description is wrong.
> 
> Since I'm no AV1 expert and have no idea what the difference between OBU and Annex B streams is,
> I can only comment on what looks like an inconsistency.

Annex B is very unlike H.264 annex b. Its adds a wrapper around time units,
making it faster to walk through displayable frames when you have the ability to
skip bytes. I've only ever seen it in tests vectors so far. My impression is
that we'll never have a hardware that requires that.

Nicolas

> 
> Regards,
> 
> 	Hans
> 
> > +        The encoder generates one Temporal Unit per buffer.
> >  .. raw:: latex
> >  
> >      \normalsize
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index becd08fdbddb857f8f2bf205d2164dc6e20e80b2..cf0b71bbe0f9d397e1e6c88433a0fc3ba11fb947 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -775,6 +775,7 @@ struct v4l2_pix_format {
> >  #define V4L2_PIX_FMT_H264_SLICE v4l2_fourcc('S', '2', '6', '4') /* H264 parsed slices */
> >  #define V4L2_PIX_FMT_HEVC_SLICE v4l2_fourcc('S', '2', '6', '5') /* HEVC parsed slices */
> >  #define V4L2_PIX_FMT_AV1_FRAME v4l2_fourcc('A', 'V', '1', 'F') /* AV1 parsed frame */
> > +#define V4L2_PIX_FMT_AV1      v4l2_fourcc('A', 'V', '0', '1') /* AV1 */
> >  #define V4L2_PIX_FMT_SPK      v4l2_fourcc('S', 'P', 'K', '0') /* Sorenson Spark */
> >  #define V4L2_PIX_FMT_RV30     v4l2_fourcc('R', 'V', '3', '0') /* RealVideo 8 */
> >  #define V4L2_PIX_FMT_RV40     v4l2_fourcc('R', 'V', '4', '0') /* RealVideo 9 & 10 */
> > 

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ