Messages in this thread | | | Subject | Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats | From | ayaka <> | Date | Mon, 2 Jan 2017 21:03:58 +0800 |
| |
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@soulik.info> >>> 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 */
| |