linux-kernel - Re: [RFC PATCH 00/11] VC8000E H.264 V4L2 Stateless Encoder

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] [day] [month] [year] [list]

Message-ID: <c666ab1bbc619cbb99fa38b96891a24ca22c9672.camel@collabora.com>
Date: Tue, 10 Jun 2025 14:19:02 -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
Subject: Re: [RFC PATCH 00/11] VC8000E H.264 V4L2 Stateless Encoder

Hi Marco,

Le vendredi 02 mai 2025 à 17:05 +0200, Marco Felsch a écrit
> 
> [1] https://github.com/bootlin/linux/tree/hantro/h264-encoding-v5.11
> [2] https://gitlab.freedesktop.org/dude/gstreamer/-/tree/h264-stateless-encoder

Can you rebase against the upstream work:

https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5676

A lot of changes Michael made in your branch are already in the upstream MR
branch. An example, in the upstream version, the src pad (CAPTURE) is already
being set before the sink pad (OUTPUT).

I'd like to open the discussion about sizes, as I'm writing things down.
In your modification, you affirm that the encoder must ignore the size
set on the CAPTURE. At the moment I tend to disagree with this
interpretation and would like some feedback.

There is couple of different sizes we'll have to support:

1. Allocation sizes
2. coded size
3. display size

My believe is that we want to split the size in 1 and 2 since the padding
added to the allocated size should not affect the amount of bits that will
be compressed. We should be able to further pad frames without increasing
the compressed size.

For this, I wanted to mimic the stateless decoders, and define the coded
size, the one that occupy space in the bitstream and found in the sequence
headers to match the CATPURE size.

3. does not exists in stateless decoders, since it has no implication
in the decoding process. This one I'll leave open for now, since its
only needed if we have to generate some headers in the kernel. We have
had a lot of discussion toward that, and if so, I will pull in the
use of S_SELECTION.

regards,
Nicolas