Re: [PATCH/RFC 15/16] media: v4l2: Add 10-, 12- and 16-bpc 4:4:4 packed VUY formats

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Nicolas,

On Thu, Sep 24, 2020 at 02:24:44PM -0400, Nicolas Dufresne wrote:
> Le mercredi 23 septembre 2020 à 05:43 +0300, Laurent Pinchart a écrit :
> > Add three new formats storing packed YUV 4:4:4 in 10-, 12- and 16-bpc
> > variants, with component order VUY. They are used by the Xilinx Video
> > Frame Buffer Read/Write IP cores.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> > ---
> >  .../media/v4l/pixfmt-packed-yuv.rst           | 55 +++++++++++++++++++
> >  include/uapi/linux/videodev2.h                |  3 +
> >  2 files changed, 58 insertions(+)
> > 
> > diff --git a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> > index 3c7c8e38b7b7..4753ee8c6b7d 100644
> > --- a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> > +++ b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> > @@ -264,6 +264,61 @@ the second byte and Y'\ :sub:`7-0` in the third byte.
> >        applications and drivers.
> >  
> >  
> > +The next table lists the packed YUV 4:4:4 formats with more than 8 bits per
> > +component. They are named similarly to the formats with less than 8 bits per
> > +components, based on the order of the Y, Cb and Cr components as seen in a
> > +word, which is then stored in memory in little endian byte order, and on the
> > +number of bits for each component.
> > +
> > +.. flat-table:: Packed YUV Image Formats (more than 8bpc)
> > +    :header-rows: 1
> > +    :stub-columns: 0
> > +
> > +    * - Identifier
> > +      - Code
> > +      - Byte 0
> > +      - Byte 1
> > +      - Byte 2
> > +      - Byte 3
> > +      - Byte 4
> > +      - Byte 5
> > +
> > +    * .. _V4L2-PIX-FMT-XVUY2101010:
> > +
> > +      - ``V4L2_PIX_FMT_XVUY2101010``
> > +      - 'VY30'
> > +
> > +      - Y'\ :sub:`7-0`
> > +      - Cb\ :sub:`5-0` Y'\ :sub:`9-8`
> > +      - Cr\ :sub:`3-0` Cb\ :sub:`9-6`
> > +      - `-`\ :sub:`1-0` Cr\ :sub:`9-4`
> > +      -
> > +
> > +    * .. _V4L2-PIX-FMT-XVUY4121212:
> > +
> > +      - ``V4L2_PIX_FMT_XVUY4121212``
> > +      - 'VY36'
> > +
> > +      - Y'\ :sub:`7-0`
> > +      - Cb\ :sub:`3-0` Y'\ :sub:`11-8`
> > +      - Cb\ :sub:`11-4`
> > +      - Cr\ :sub:`7-0`
> > +      - `-`\ :sub:`3-0` Cr\ :sub:`11-8`
> > +      -
> > +
> > +    * .. _V4L2-PIX-FMT-VUY161616:
> > +
> > +      - ``V4L2_PIX_FMT_VUY161616``
> > +      - 'VY40'
> > +
> > +      - Y'\ :sub:`7-0`
> > +      - Y'\ :sub:`15-8`
> > +      - Cb\ :sub:`7-0`
> > +      - Cb\ :sub:`15-8`
> > +      - Cr\ :sub:`7-0`
> > +      - Cr\ :sub:`15-8`
> > +
> > +
> >  4:2:2 Subsampling
> >  =================
> >  
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 503a938ea98c..9b4cab651df7 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -605,6 +605,9 @@ struct v4l2_pix_format {
> >  #define V4L2_PIX_FMT_YUVA32  v4l2_fourcc('Y', 'U', 'V', 'A') /* 32  YUVA-8-8-8-8  */
> >  #define V4L2_PIX_FMT_YUVX32  v4l2_fourcc('Y', 'U', 'V', 'X') /* 32  YUVX-8-8-8-8  */
> >  #define V4L2_PIX_FMT_M420    v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1 line uv interleaved */
> > +#define V4L2_PIX_FMT_XVUY2101010 v4l2_fourcc('V', 'Y', '3', '0') /* 32  XVUY-2-10-10-10 */
> > +#define V4L2_PIX_FMT_XVUY4121212 v4l2_fourcc('V', 'Y', '3', '6') /* 40  XVUY-4-12-12-12 */
> > +#define V4L2_PIX_FMT_VUY161616 v4l2_fourcc('V', 'Y', '4', '8') /* 48  VUY-16-16-16 */
> 
> That is very hard to read. I'm fine with being more verbose, but I
> think it would be nice if it remains human readable. A possible fix
> could be:
> 
>   V4L2_PIX_FMT_XVUY_2_10_10_10

Hans has proposed an interleave naming scheme in the review of 13/16.
This would become X2V10U10Y10. He also mentioned an alternative option
that would match your proposal above. I don't have a strong preference.
Can you and Hans agree on the best option ?

> Another approach is a bit-per-component and pixel size approach. That
> one would be XYUV10_32. It is more cryptic, and you need more doc to
> understand.
> 
> That brings me to endianness, I believe it does matter for these
> unaligned component, so that should be documented (little).

That's already documented in
Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst.

> >  /* two planes -- one Y, one Cr + Cb interleaved  */
> >  #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2') /* 12  Y/CbCr 4:2:0  */

-- 
Regards,

Laurent Pinchart



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux