Le lundi 30 janvier 2023 à 08:15 +0000, Ming Qian a écrit :
> > > diff --git a/include/uapi/linux/videodev2.h
> > > b/include/uapi/linux/videodev2.h index 1befd181a4cc..5448aa3b7858
> > > 100644
> > > --- a/include/uapi/linux/videodev2.h
> > > +++ b/include/uapi/linux/videodev2.h
> > > @@ -626,12 +626,14 @@ struct v4l2_pix_format {
> > > #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') /* 24
> > > Y/CbCr
> > 4:2:0 10-bit per component */
> > > +#define V4L2_PIX_FMT_P012 v4l2_fourcc('P', '0', '1', '2') /* 24
> > > Y/CbCr
> > 4:2:0 12-bit per component */
> > >
> > > /* 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 */
> > > #define V4L2_PIX_FMT_NV21M v4l2_fourcc('N', 'M', '2', '1') /* 21
> > > Y/CrCb
> > 4:2:0 */
> > > #define V4L2_PIX_FMT_NV16M v4l2_fourcc('N', 'M', '1', '6') /* 16
> > > Y/CbCr
> > 4:2:2 */
> > > #define V4L2_PIX_FMT_NV61M v4l2_fourcc('N', 'M', '6', '1') /* 16
> > > Y/CrCb
> > 4:2:2 */
> > > +#define V4L2_PIX_FMT_P012M v4l2_fourcc('P', 'M', '1', '2') /* 24
> > > Y/CbCr
> > 4:2:0 12-bit per component */
> >
> > The name of the V4L2_PIX_FMT_ defines in this series are hard to decode.
> >
> > In this case is it derived from V4L2_PIX_FMT_P010, which really should have
> > been named differently, but it's too late now :-(
> >
> > So I guess we'll stick with this naming, but it's not obvious what 'P012'
> > means
> > without referring to documentation.
> >
> > Oh well.
> >
> > Regards,
> >
> > Hans
>
> Hi Hans,
> I'll update the format name, as you know, the P012 is following the P010,
> as they are almost the same, and the Y212 comes from gstreamer
> (GST_VIDEO_FORMAT_Y212_LE), then I did some naming like that.
> I'll correct them in v2 patch.
I agree these naming are not obvious. In GStreamer, appart from the _LE part,
we've had this historical tendency to just stick with Microsoft names when they
exist. Though Microsoft only define 10 and 16bits (P010/P016, Y210 and Y216). In
this case, the 12 has is derived from it.
https://learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats
While P010 is very commonly seen, I don't know if Y210/Y212/Y216 is a great
idea. It is a 16bit component width version of YUYV, which as we know exist in
all sort of swizzling. So the Microsoft name will be hard to extend to other
component order. My argument of keeping it this way though is that it matches
the other copy of pixel formats definition that exist in Linux, which is
drm_fourcc.h.
Nicolas
