From: Nicolas Dufresne <nicolas@ndufresne.ca>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-media@vger.kernel.org,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Dylan Yip <dylany@xilinx.com>, Vishal Sagar <vsagar@xilinx.com>
Subject: Re: [PATCH/RFC 15/16] media: v4l2: Add 10-, 12- and 16-bpc 4:4:4 packed VUY formats
Date: Mon, 02 Nov 2020 15:39:25 -0500 [thread overview]
Message-ID: <62f00dd8b515a94af1e993ad4c3586628d3e2954.camel@ndufresne.ca> (raw)
In-Reply-To: <20201101003811.GD4225@pendragon.ideasonboard.com>
Le dimanche 01 novembre 2020 à 02:38 +0200, Laurent Pinchart a écrit :
> 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@ideasonboard.com>
> > > ---
> > > .../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 ?
Not that I have a strong preference, they equally describe the format.
1. V4L2_PIX_FMT_X2V10U10Y10:
This is more compact and more likely to fit 80 to 100 chars when
coding.
2. V4L2_PIX_FMT_XVUY_2_10_10_10:
It splits the component order and leave the component size easy to
read. It is overall easier to identify on first read.
I read more code then I write, so my obvious preference would be 2.,
but I'm fine with any.
> > 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.
Ack.
>
> > > /* 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 */
>
next prev parent reply other threads:[~2020-11-02 20:40 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-23 2:43 [PATCH/RFC 00/16] media: Add new pixel formats for Xilinx v-frmbuf Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 01/16] media: videodev2.h: Remove unneeded comment about 4CC value Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 02/16] media: videodev2.h: Move HI240 format to vendor-specific section Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 03/16] media: videodev2.h: Move HM12 format to YUV semi-planar section Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 04/16] media: doc: pixfmt-rgb: Remove layout table for packed RGB formats Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 05/16] media: doc: pixfmt-rgb: Add title for deprecated formats Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 06/16] media: doc: pixfmt-rgb: Clarify naming scheme for RGB formats Laurent Pinchart
2020-09-24 18:05 ` Nicolas Dufresne
2020-10-31 23:26 ` Laurent Pinchart
2020-10-01 13:33 ` Hans Verkuil
2020-11-01 0:11 ` Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 07/16] media: doc: pixfmt-yuv: Document subsampling in more details Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 08/16] media: doc: pixfmt-yuv: Move all packed YUV formats to common file Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 09/16] media: doc: pixfmt-packed-yuv: Fill padding bits with '-' Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 10/16] media: doc: pixfmt-packed-yuv: Express 4:4:4 formats in a more compact way Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 11/16] media: doc: pixfmt-packed-yuv: Clarify naming scheme for 4:4:4 formats Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 12/16] media: doc: pixfmt-yuv: Move all luma-only YUV formats to common file Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 13/16] media: v4l2: Add 10-, 12- and 16-bpc BGR formats Laurent Pinchart
2020-10-01 13:44 ` Hans Verkuil
2020-11-01 0:30 ` Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 14/16] media: v4l2: Add a few missing packed YUV 4:4:4 formats Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 15/16] media: v4l2: Add 10-, 12- and 16-bpc 4:4:4 packed VUY formats Laurent Pinchart
2020-09-24 18:24 ` Nicolas Dufresne
2020-11-01 0:38 ` Laurent Pinchart
2020-11-02 20:39 ` Nicolas Dufresne [this message]
2020-11-02 22:08 ` Laurent Pinchart
2020-09-23 2:43 ` [PATCH/RFC 16/16] media: v4l2: Add 10- and 12-bpc luma-only formats with linear packing Laurent Pinchart
2020-09-24 18:27 ` Nicolas Dufresne
2020-11-01 0:42 ` Laurent Pinchart
2020-11-02 20:45 ` Nicolas Dufresne
2020-11-02 22:14 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=62f00dd8b515a94af1e993ad4c3586628d3e2954.camel@ndufresne.ca \
--to=nicolas@ndufresne.ca \
--cc=dylany@xilinx.com \
--cc=hverkuil-cisco@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=vsagar@xilinx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).