Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[ayaka]

On 01/02/2017 07:07 PM, Sakari Ailus wrote:
> Hi,
>
> On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote:
> > On 01/02/2017 05:10 PM, Sakari Ailus wrote:
> > > Hi Randy,
> > >
> > > Thanks for the patch.
> > >
> > > On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
> > > > The formats added by this patch are:
> > > > 	V4L2_PIX_FMT_P010
> > > > 	V4L2_PIX_FMT_P010M
> > > > Currently, none of driver uses those format, but some video device
> > > > has been confirmed with could as those format for video output.
> > > > The Rockchip's new decoder has supported those format for profile_10
> > > > HEVC/AVC video.
> > > >
> > > > Signed-off-by: Randy Li <ayaka@xxxxxxxxxxx>
> > > If the format resembles the existing formats but on a different bit depth,
> > > it should be named in similar fashion.
> > Do you mean it would be better if it is called as NV12_10?
> If it otherwise resembles NV12 but just has 10 bits per pixel, I think
> NV12_10 is a good name for it.
The main reason I don't like it is that there is a various of software 
having used the P010 for this kind of pixel format. It would leadi a 
conflict between them(and I never saw it is used as NV12_10), as the 
P010 is more common to be used.
I left a problem unsolved for P010 in v4l2, P010 have two variant, 
little endian and big endian. Which could be easy identified in drm 
driver(there is a flag for all the big endian pixel format).
> > > Could you also add ReST documentation for the format, please?
> > I will.
> > > The common requirement for merging patches that change interfaces has been
> > > that there's a user for that change. It'll still help you to get this
> > The kernel used in rockchip has supported that format in drm driver, but
> > just we don't have a agreement about the pixel format. As the Gstreamer and
> > some others would call it with a P010_ prefix, but Mark(rockchip's drm
> > author) prefer the something like NV12_10, that is why I sent out those
> > patches, I want the upstream decided its final name.
> Ack.
>
> I think we haven't really tried to unify the format naming in the past
> between the two subsystems. If existing conventions exist on both regarding
> this format, then it's probably better to follow those.
>
> Cc Laurent as well.
>
> > > reviewed now so the interface that the future hopefully-in-mainline driver
> > > provides will not change.
> > >
> > > > ---
> > > >   include/uapi/linux/videodev2.h | 2 ++
> > > >   1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > > > index 46e8a2e3..9e03f20 100644
> > > > --- a/include/uapi/linux/videodev2.h
> > > > +++ b/include/uapi/linux/videodev2.h
> > > > @@ -551,6 +551,7 @@ struct v4l2_pix_format {
> > > >   #define V4L2_PIX_FMT_NV61    v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 4:2:2  */
> > > >   #define V4L2_PIX_FMT_NV24    v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 4:4:4  */
> > > >   #define V4L2_PIX_FMT_NV42    v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 4:4:4  */
> > > > +#define V4L2_PIX_FMT_P010    v4l2_fourcc('P', '0', '1', '0') /* 15  Y/CbCr 4:2:0, 10 bits per channel */
> > > >   /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
> > > >   #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 4:2:0  */
> > > > @@ -559,6 +560,7 @@ struct v4l2_pix_format {
> > > >   #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /* 16  Y/CrCb 4:2:2  */
> > > >   #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 4:2:0 64x32 macroblocks */
> > > >   #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  Y/CbCr 4:2:0 16x16 macroblocks */
> > > > +#define V4L2_PIX_FMT_P010M   v4l2_fourcc('P', 'M', '1', '0') /* 15  Y/CbCr 4:2:0, 10 bits per channel */
> > > >   /* three planes - Y Cb, Cr */
> > > >   #define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 4:1:0     */