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

Hi Sven

On Fri, Jul 10, 2026 at 10:36:53AM +0200, Sven Püschel wrote:
> Hi Jacopo,
>
> On 7/9/26 11:35 AM, Jacopo Mondi wrote:
> > Hi Tommaso
> >
> > On Wed, Jul 08, 2026 at 06:14:03PM +0200, Tommaso Merciai wrote:
> >
> > > + *
> > > + * @pixfmt: pointer to the &struct v4l2_pix_format to be filled
> > > + * @pixelformat: the V4L2 pixel format (V4L2_PIX_FMT_*)
> > > + * @width: image width in pixels
> > > + * @height: image height in pixels
> > > + * @stride_alignment: stride alignment in bytes, must be a power of 2
> > > + *
> > > + * Fills all fields of @pixfmt for the given pixel format, dimensions, and
> > > + * stride alignment. Only formats stored in a single memory plane are
> > > + * supported; returns -EINVAL for multi-memory-plane formats.
> > > + *
> > > + * @pixfmt->bytesperline is set to the stride of the primary (plane 0) plane,
> > > + * rounded up to a multiple of @stride_alignment. For formats that store
> > > + * multiple component planes in a single memory buffer (e.g. NV12), the
> > > + * alignment applied to each component plane's stride is scaled relative to
> > > + * @stride_alignment so that the chroma stride remains consistently derivable
> > Does this rather mean that
> >
> > "For formats that store multiple component planes in a single memory
> > buffer (e.g. NV12), the alignment applied to each component plane is
> > the first plane @stride_alignment scaled by the plane's sub-sampling
> > ratio" or have I mis-read this ?
>
> No, for the example of NV12, no stride will get scaled (although the
> sub-sampling of 4:2:0, resulting in a vdiv and hdiv of 2).

Ah, I had looked at v4l2_format_plane_stride() for the NV12 case where
byte_alignment gets adjusted for the second plane as:

byte_alignment *= DIV_ROUND_UP(info->bpp[1], info->hdiv * info->bpp[0]);

which for NV12 resolves at *= 1

and I got confused

Indeed this is not just

"the first plane @stride_alignment scaled by the plane's sub-sampling
ratio"

I proposed

>
> 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 ?

> intention is that for non-mp (not ending with M) formats we might do the
> scaling (e.g. YUV420 will have it's Y component stride alignment scaled to
> not break the u and v stride alignments, but YUV420M not)
>
> Sincerely
>     Sven
>
>