Re: [PATCH v3 2/4] media: v4l2-common: Add v4l2_fill_pixfmt_aligned() helper

From: Sven Püschel

Date: Fri Jul 10 2026 - 08:27:31 EST

Hi Jacopo,

On 7/10/26 2:15 PM, Jacopo Mondi wrote:
Hi Sven

On Fri, Jul 10, 2026 at 01:54:06PM +0200, Sven Püschel wrote:
Hi Jacopo,

On 7/10/26 11:38 AM, Jacopo Mondi wrote:
This is due to the fact, that while we have a hdiv of 2 we also interleave
the cb and cr parts in a single plane, which results in the stride being the
same number of bytes as for the y plane (and vdiv isn't relevant for the
stride).

Therefore the stride scaling also respects the bits per plane (bpp) value to
determine the scaling.

@Tommaso : While the sentence looks ok, the NV12 example is misguided. The
I guess the usage of NV12 was as example of a "formats that store
multiple component planes in a single memory"

NV24/42 works the same, but being 444 it needs the chroma plane stride to
be a multiple of the fist plane stride and might prove as a better
example ?

My potential concern is that NV as an example misguides the reader into one
of the following:

- It's only for formats which interleave cb/cr into one plane (whereas
YUV420 also gets scaled)
- NV24 in the example being though of including the NV24M variant (whereas
latter won't be affected)
M variants are not supported by the single-planar APIs
https://docs.kernel.org/userspace-api/media/v4l/pixfmt-yuv-planar.html

Some planar formats allow planes to be placed in independent memory
locations. They are identified by an ‘M’ suffix in their name (such as
in V4L2_PIX_FMT_NV12M). Those formats are intended to be used only in
drivers and applications that support the multi-planar API,

And here we're dealing with single-planar API only if I'm not mistaken

Oh, sorry. Assumed that the added description of both functions would be similar/identical, which isn't the case.

Given this, I'm fine with the wording and agree to just change the example to smth. else than NV12.

Sincerely
    Sven