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

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


> Maybe smth. like YUV420 but not YUV420M is a better example (could also be
> NV24 but not NV24M)?
>
> Sincerely
>     Sven
>