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

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