linux-kernel - Re: [RFC PATCH 03/11] media: uapi: add nal unit header fields to encode

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: <2d82e4e0aa4c244e8b2d3f1e46e92760cd6238d7.camel@collabora.com>
Date: Fri, 02 May 2025 12:38:11 -0400
From: Nicolas Dufresne <nicolas.dufresne@...labora.com>
To: Marco Felsch <m.felsch@...gutronix.de>, benjamin.gaignard@...labora.com,
 	p.zabel@...gutronix.de, mchehab@...nel.org, shawnguo@...nel.org, Sascha
 Hauer	 <s.hauer@...gutronix.de>, kernel@...gutronix.de, festevam@...il.com,
 	robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 paulk@...-base.io, 	hverkuil@...all.nl, laurent.pinchart@...asonboard.com, 
	sebastian.fricke@...labora.com, ming.qian@....com
Cc: linux-kernel@...r.kernel.org, linux-media@...r.kernel.org, 
	linux-rockchip@...ts.infradead.org, imx@...ts.linux.dev, 
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org, Michael
 Tretter <m.tretter@...gutronix.de>
Subject: Re: [RFC PATCH 03/11] media: uapi: add nal unit header fields to
 encode_params

Hi,

Le vendredi 02 mai 2025 à 17:05 +0200, Marco Felsch a écrit :
> From: Michael Tretter <m.tretter@...gutronix.de>
> 
> The VEPU540 and VEPU580 may prepare the NAL unit headers in the coded
> params. These values have to be provided by user space and be written
> into the hardware registers.

To be reworked in future version. This commit message refers to RK356x and
RK3688 encoders block from Rockchip. Though, its possible this applies for
Hantro IP too.

Nicolas
 
> Furthermore, nal_ref_idc indicates if a picture will be used as
> reference and is a hint to the driver, if it needs to keep the
> reconstructed buffer or not.
> 
> Signed-off-by: Michael Tretter <m.tretter@...gutronix.de>
> ---
>  include/uapi/linux/v4l2-controls.h | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index 670f822ee758..a8df393c9ead 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -1694,6 +1694,9 @@ struct v4l2_ctrl_h264_decode_params {
>  	__u32 flags;
>  };
>  
> +#define V4L2_H264_NAL_CODED_SLICE_NON_IDR_PIC	1
> +#define V4L2_H264_NAL_CODED_SLICE_IDR_PIC	5
> +
>  #define V4L2_CID_STATELESS_H264_ENCODE_PARAMS	(V4L2_CID_CODEC_STATELESS_BASE + 8)
>  
>  /**
> @@ -1719,6 +1722,8 @@ struct v4l2_ctrl_h264_decode_params {
>   * @pic_init_qp_minus26: initial value minus 26 of luma qp for each slice.
>   * @chroma_qp_index_offset: offset that shall be added to qp luma for addressing the
>   * table of qp chroma values for the Cb chroma component.
> + * @nal_ref_idc: nal_ref_idc for the header of the generated NAL unit
> + * @nal_unit_type: one of the V4L2_H264_NAL_CODED_SLICE_{} values
>   * @flags: combination of V4L2_H264_ENCODE_FLAG_{} flags.
>   * @reference_ts: timestamp of the V4L2 buffer to use as reference
>   */
> @@ -1751,6 +1756,16 @@ struct v4l2_ctrl_h264_encode_params {
>  
>  	__u32 flags; /* V4L2_H264_ENCODE_FLAG_ */
>  
> +	/*
> +	 * If nal_ref_idc is 0, the NAL unit won't be used as reference by
> +	 * later NAL units. Any other value indicates that the NAL unit may be
> +	 * used as reference.
> +	 */
> +	__u8 nal_ref_idc;
> +
> +	/* TODO Can we infer the nal_unit_type from the slice_type? */
> +	__u8 nal_unit_type;
> +
>  	/* Reference */
>  
>  	__u64 reference_ts;