Re: [PATCH v4 1/6] media: v4l2: Add NV15 and NV20 pixel formats

[Nicolas Dufresne <nicolas.dufresne@collabora.com>]

Le samedi 29 mars 2025 à 00:09 +0100, Diederik de Haas a écrit :
> Hi Detlev,
> 
> On Tue Mar 25, 2025 at 10:22 PM CET, Detlev Casanova wrote:
> > From: Jonas Karlman <jonas@kwiboo.se>
> > 
> > Add NV15 and NV20 pixel formats used by the Rockchip Video Decoder for
> > 10-bit buffers.
> > 
> > NV15 and NV20 is 10-bit 4:2:0/4:2:2 semi-planar YUV formats similar to
> > NV12 and NV16, using 10-bit components with no padding between each
> > component. Instead, a group of 4 luminance/chrominance samples are
> > stored over 5 bytes in little endian order:
> > 
> > YYYY = UVUV = 4 * 10 bits = 40 bits = 5 bytes
> > 
> > The '15' and '20' suffix refers to the optimum effective bits per pixel
> > which is achieved when the total number of luminance samples is a
> > multiple of 8 for NV15 and 4 for NV20.
> > 
> > Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> > Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> > Tested-by: Christopher Obbard <chris.obbard@collabora.com>
> > ---
> >  .../media/v4l/pixfmt-yuv-planar.rst           | 128 ++++++++++++++++++
> >  drivers/media/v4l2-core/v4l2-common.c         |   2 +
> >  drivers/media/v4l2-core/v4l2-ioctl.c          |   2 +
> >  include/uapi/linux/videodev2.h                |   2 +
> >  4 files changed, 134 insertions(+)
> > 
> > diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
> > index b788f69338554..22cad8c9726bf 100644
> > --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
> > +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
> > @@ -79,6 +79,13 @@ All components are stored with the same number of bits per component.
> >        - Cr, Cb
> >        - Yes
> >        - Linear
> > +    * - V4L2_PIX_FMT_NV15
> > +      - 'NV15'
> > +      - 10
> > +      - 4:2:0
> > +      - Cb, Cr
> > +      - Yes
> > +      - Linear
> 
> In your cover letter you mentioned:
> Imported improvements from [1]
> [1]: https://lore.kernel.org/linux-media/20250225-rkvdec_h264_high10_and_422_support-v7-2-7992a68a4910@collabora.com/
> 
> The changelog of "media: rkvdec: Add H.264 High 10 and 4:2:2 profile
> support" v7 had this:
> - Move V4L2_PIX_FMT_NV15/V4L2_PIX_FMT_NV20 documentation as suggested
> 
> Following a comment on v6 of that series.
> 
> But it seems these blocks are now placed at the location as it was in
> the v6 series, thus NOT importing its improvements?

The other series have been partially accepted into media-commiters next
branch, including this patch. Meaning you can simply remove that patch
in your next submission.

regards,
Nicolas

> 
> >      * - V4L2_PIX_FMT_NV12M
> >        - 'NM12'
> >        - 8
> > @@ -172,6 +179,13 @@ All components are stored with the same number of bits per component.
> >        - Cr, Cb
> >        - Yes
> >        - Linear
> > +    * - V4L2_PIX_FMT_NV20
> > +      - 'NV20'
> > +      - 10
> > +      - 4:2:2
> > +      - Cb, Cr
> > +      - Yes
> > +      - Linear
> >      * - V4L2_PIX_FMT_NV16M
> >        - 'NM16'
> >        - 8
> 
> The same thing seemed to have happened here?
> 
> Cheers,
>   Diederik
> 
> > @@ -302,6 +316,57 @@ of the luma plane.
> >        - Cr\ :sub:`11`
> >  
> >  
> > +.. _V4L2-PIX-FMT-NV15:
> > +
> > +NV15
> > +----
> > +
> > +Semi-planar 10-bit YUV 4:2:0 format similar to NV12, using 10-bit components
> > +with no padding between each component. A group of 4 components are stored over
> > +5 bytes in little endian order.
> > +
> > +.. flat-table:: Sample 4x4 NV15 Image (1 byte per cell)
> > +    :header-rows:  0
> > +    :stub-columns: 0

-- 
Nicolas Dufresne
Principal Engineer at Collabora