[PATCH v2 0/2] Add pixel formats for 10/16 bits YUV video

[PATCH v2 0/2] Add pixel formats for 10/16 bits YUV video

[Randy Li]

Those pixel formats mainly comes from Gstreamer and ffmpeg. Currently,
the VOP(video output mixer) found on RK3288 and future support
those 10 bits pixel formats are input. Also the decoder on RK3288
could use them as output.

The fourcc is not enough to store the endian information for those
pixel formats in v4l2, as it doesn't have a flag like drm does.

I have not met the usage of those 16 bits per-channel format,
it is a very large color range, even the DSLR only use 12 bits.

Randy Li (2):
  drm_fourcc: Add new P010, P016 video format
  [media] v4l: Add 10/16-bits per channel YUV pixel formats

 Documentation/media/uapi/v4l/pixfmt-p010.rst  |  86 ++++++++++++++++
 Documentation/media/uapi/v4l/pixfmt-p010m.rst |  94 ++++++++++++++++++
 Documentation/media/uapi/v4l/pixfmt-p016.rst  | 126 ++++++++++++++++++++++++
 Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 ++++++++++++++++++++++++++
 drivers/gpu/drm/drm_fourcc.c                  |   3 +
 include/uapi/drm/drm_fourcc.h                 |   2 +
 include/uapi/linux/videodev2.h                |   4 +
 7 files changed, 451 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst

-- 
2.7.4

[PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format

[Randy Li]

P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format. Rockchip's vop support this
video format(little endian only) as the input video format.

P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
per channel video format.

Signed-off-by: Randy Li <ayaka@soulik.info>

drm
---
 drivers/gpu/drm/drm_fourcc.c  | 3 +++
 include/uapi/drm/drm_fourcc.h | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..23c8e99 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
 		{ .format = DRM_FORMAT_UYVY,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
 		{ .format = DRM_FORMAT_VYUY,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
 		{ .format = DRM_FORMAT_AYUV,		.depth = 0,  .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+		/* FIXME a pixel in Y for P010 is 10 bits */
+		{ .format = DRM_FORMAT_P010,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
+		{ .format = DRM_FORMAT_P016,		.depth = 0,  .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
 	};
 
 	unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e1bb7f..ecc2e05e5 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -119,6 +119,8 @@ extern "C" {
 #define DRM_FORMAT_NV61		fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */
 #define DRM_FORMAT_NV24		fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
 #define DRM_FORMAT_NV42		fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
+#define DRM_FORMAT_P010		fourcc_code('P', '0', '1', '0') /* 2x2 subsampled Cr:Cb plane 10 bits per channel */
+#define DRM_FORMAT_P016		fourcc_code('P', '0', '1', '6') /* 2x2 subsampled Cr:Cb plane 16 bits per channel */
 
 /*
  * 3 plane YCbCr
-- 
2.7.4

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

[Randy Li]

The formats added by this patch are:
	V4L2_PIX_FMT_P010
	V4L2_PIX_FMT_P010M
	V4L2_PIX_FMT_P016
	V4L2_PIX_FMT_P016M
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 10 bits format for
profile_10 HEVC/AVC video.

Signed-off-by: Randy Li <ayaka@soulik.info>

v4l2
---
 Documentation/media/uapi/v4l/pixfmt-p010.rst  |  86 ++++++++++++++++
 Documentation/media/uapi/v4l/pixfmt-p010m.rst |  94 ++++++++++++++++++
 Documentation/media/uapi/v4l/pixfmt-p016.rst  | 126 ++++++++++++++++++++++++
 Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 ++++++++++++++++++++++++++
 include/uapi/linux/videodev2.h                |   4 +
 5 files changed, 446 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-p010.rst b/Documentation/media/uapi/v4l/pixfmt-p010.rst
new file mode 100644
index 0000000..82b300c
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010.rst
@@ -0,0 +1,86 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010:
+
+******************************************************
+V4L2_PIX_FMT_P010 ('P010')
+******************************************************
+
+
+V4L2_PIX_FMT_P010
+Formats with ½ horizontal and vertical chroma resolution. One luminance and
+one chrominance plane with alternating
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``
+
+
+Description
+===========
+
+It is a two-plane versions of the YUV 4:2:0 format. The three
+components are separated into two sub-images or planes. The Y plane is
+first. The Y plane has 10 bits per pixel. For ``V4L2_PIX_FMT_P010``, a
+combined CbCr plane immediately follows the Y plane in memory. The CbCr
+plane is the same width, in bytes, as the Y plane (and of the image),
+but is half as tall in pixels. Each CbCr pair belongs to four pixels.
+For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
+Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+
+**Color Sample Location..**
+
+.. flat-table::
+    :header-rows:  0
+    :stub-columns: 0
+
+    * -
+      - 0
+      -
+      - 1
+      - 2
+      -
+      - 3
+    * - 0
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
+    * -
+      -
+      - C
+      -
+      -
+      - C
+      -
+    * - 1
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
+    * -
+    * - 2
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
+    * -
+      -
+      - C
+      -
+      -
+      - C
+      -
+    * - 3
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010m.rst b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
new file mode 100644
index 0000000..80194a1
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
@@ -0,0 +1,94 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010M:
+
+***********************************************************************************
+V4L2_PIX_FMT_P010 ('P010')
+***********************************************************************************
+
+
+V4L2_PIX_FMT_P010M
+Variation of ``V4L2_PIX_FMT_P010`` with planes non contiguous in memory.
+
+
+Description
+===========
+
+This is a multi-planar, two-plane version of the YUV 4:2:0 format. The
+three components are separated into two sub-images or planes.
+``V4L2_PIX_FMT_P010M`` differs from ``V4L2_PIX_FMT_P010`` in that the
+two planes are non-contiguous in memory, i.e. the chroma plane do not
+necessarily immediately follows the luma plane. The luminance data
+occupies the first plane. The Y plane has one byte per pixel. In the
+second plane there is a chrominance data with alternating chroma
+samples. The CbCr plane is the same width, in bytes, as the Y plane (and
+of the image), but is half as tall in pixels. Each CbCr pair belongs to
+four pixels. For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to
+Y'\ :sub:`00`, Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+
+``V4L2_PIX_FMT_P010M`` is intended to be used only in drivers and
+applications that support the multi-planar API, described in
+:ref:`planar-apis`.
+
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+**Color Sample Location..**
+
+
+
+.. flat-table::
+    :header-rows:  0
+    :stub-columns: 0
+
+    * -
+      - 0
+      -
+      - 1
+      - 2
+      -
+      - 3
+    * - 0
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
+    * -
+      -
+      - C
+      -
+      -
+      - C
+      -
+    * - 1
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
+    * -
+    * - 2
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
+    * -
+      -
+      - C
+      -
+      -
+      -
+      - C
+      -
+    * - 3
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
diff --git a/Documentation/media/uapi/v4l/pixfmt-p016.rst b/Documentation/media/uapi/v4l/pixfmt-p016.rst
new file mode 100644
index 0000000..ac341a1
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p016.rst
@@ -0,0 +1,126 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P016:
+
+******************************************************
+V4L2_PIX_FMT_P016 ('P016')
+******************************************************
+
+
+V4L2_PIX_FMT_P016
+Formats with ½ horizontal and vertical chroma resolution. One luminance and
+one chrominance plane with alternating
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``
+
+
+Description
+===========
+
+It is a two-plane versions of the YUV 4:2:0 format. The three
+components are separated into two sub-images or planes. The Y plane is
+first. The Y plane has 16 bits per pixel. For ``V4L2_PIX_FMT_P016``, a
+combined CbCr plane immediately follows the Y plane in memory. The CbCr
+plane is the same width, in bytes, as the Y plane (and of the image),
+but is half as tall in pixels. Each CbCr pair belongs to four pixels.
+For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
+Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+**Byte Order.**
+Each cell is two bytes.
+
+
+.. flat-table::
+    :header-rows:  0
+    :stub-columns: 0
+
+    * - start + 0:
+      - Y'\ :sub:`00`
+      - Y'\ :sub:`01`
+      - Y'\ :sub:`02`
+      - Y'\ :sub:`03`
+    * - start + 4:
+      - Y'\ :sub:`10`
+      - Y'\ :sub:`11`
+      - Y'\ :sub:`12`
+      - Y'\ :sub:`13`
+    * - start + 8:
+      - Y'\ :sub:`20`
+      - Y'\ :sub:`21`
+      - Y'\ :sub:`22`
+      - Y'\ :sub:`23`
+    * - start + 12:
+      - Y'\ :sub:`30`
+      - Y'\ :sub:`31`
+      - Y'\ :sub:`32`
+      - Y'\ :sub:`33`
+    * - start + 16:
+      - Cb\ :sub:`00`
+      - Cr\ :sub:`00`
+      - Cb\ :sub:`01`
+      - Cr\ :sub:`01`
+    * - start + 20:
+      - Cb\ :sub:`10`
+      - Cr\ :sub:`10`
+      - Cb\ :sub:`11`
+      - Cr\ :sub:`11`
+
+
+
+**Color Sample Location..**
+
+.. flat-table::
+    :header-rows:  0
+    :stub-columns: 0
+
+    * -
+      - 0
+      -
+      - 1
+      - 2
+      -
+      - 3
+    * - 0
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
+    * -
+      -
+      - C
+      -
+      -
+      - C
+      -
+    * - 1
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
+    * -
+    * - 2
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
+    * -
+      -
+      - C
+      -
+      -
+      - C
+      -
+    * - 3
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
diff --git a/Documentation/media/uapi/v4l/pixfmt-p016m.rst b/Documentation/media/uapi/v4l/pixfmt-p016m.rst
new file mode 100644
index 0000000..ff2a554
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p016m.rst
@@ -0,0 +1,136 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P016M:
+
+***********************************************************************************
+V4L2_PIX_FMT_P016 ('P016')
+***********************************************************************************
+
+
+V4L2_PIX_FMT_P016M
+Variation of ``V4L2_PIX_FMT_P016`` with planes non contiguous in memory.
+
+
+Description
+===========
+
+This is a multi-planar, two-plane version of the YUV 4:2:0 format. The
+three components are separated into two sub-images or planes.
+``V4L2_PIX_FMT_P016M`` differs from ``V4L2_PIX_FMT_P016`` in that the
+two planes are non-contiguous in memory, i.e. the chroma plane do not
+necessarily immediately follows the luma plane. The luminance data
+occupies the first plane. The Y plane has one byte per pixel. In the
+second plane there is a chrominance data with alternating chroma
+samples. The CbCr plane is the same width, in bytes, as the Y plane (and
+of the image), but is half as tall in pixels. Each CbCr pair belongs to
+four pixels. For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to
+Y'\ :sub:`00`, Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+
+``V4L2_PIX_FMT_P016M`` is intended to be used only in drivers and
+applications that support the multi-planar API, described in
+:ref:`planar-apis`.
+
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+
+**Byte Order.**
+Each cell is two bytes.
+
+.. flat-table::
+    :header-rows:  0
+    :stub-columns: 0
+
+    * - start0 + 0:
+      - Y'\ :sub:`00`
+      - Y'\ :sub:`01`
+      - Y'\ :sub:`02`
+      - Y'\ :sub:`03`
+    * - start0 + 4:
+      - Y'\ :sub:`10`
+      - Y'\ :sub:`11`
+      - Y'\ :sub:`12`
+      - Y'\ :sub:`13`
+    * - start0 + 8:
+      - Y'\ :sub:`20`
+      - Y'\ :sub:`21`
+      - Y'\ :sub:`22`
+      - Y'\ :sub:`23`
+    * - start0 + 12:
+      - Y'\ :sub:`30`
+      - Y'\ :sub:`31`
+      - Y'\ :sub:`32`
+      - Y'\ :sub:`33`
+    * -
+    * - start1 + 0:
+      - Cb\ :sub:`00`
+      - Cr\ :sub:`00`
+      - Cb\ :sub:`01`
+      - Cr\ :sub:`01`
+    * - start1 + 4:
+      - Cb\ :sub:`10`
+      - Cr\ :sub:`10`
+      - Cb\ :sub:`11`
+      - Cr\ :sub:`11`
+
+
+
+**Color Sample Location..**
+
+
+
+.. flat-table::
+    :header-rows:  0
+    :stub-columns: 0
+
+    * -
+      - 0
+      -
+      - 1
+      - 2
+      -
+      - 3
+    * - 0
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
+    * -
+      -
+      - C
+      -
+      -
+      - C
+      -
+    * - 1
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
+    * -
+    * - 2
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
+    * -
+      -
+      - C
+      -
+      -
+      -
+      - C
+      -
+    * - 3
+      - Y
+      -
+      - Y
+      - Y
+      -
+      - Y
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 46e8a2e3..43b61f3 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -551,6 +551,8 @@ 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') /* 20  Y/CbCr 4:2:0, 10 bits per channel */
+#define V4L2_PIX_FMT_P016    v4l2_fourcc('P', '0', '1', '6') /* 32  Y/CbCr 4:2:0, 16 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 +561,8 @@ 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') /* 20  Y/CbCr 4:2:0, 10 bits per channel */
+#define V4L2_PIX_FMT_P016M   v4l2_fourcc('P', 'M', '1', '6') /* 32  Y/CbCr 4:2:0, 16 bits per channel */
 
 /* three planes - Y Cb, Cr */
 #define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 4:1:0     */
-- 
2.7.4

Re: [PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format

[Daniel Stone]

Hi Randy,

On 4 January 2017 at 16:29, Randy Li <ayaka@soulik.info> wrote:
> index 90d2cc8..23c8e99 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
>                 { .format = DRM_FORMAT_UYVY,            .depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>                 { .format = DRM_FORMAT_VYUY,            .depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>                 { .format = DRM_FORMAT_AYUV,            .depth = 0,  .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> +               /* FIXME a pixel in Y for P010 is 10 bits */
> +               { .format = DRM_FORMAT_P010,            .depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },

It seems like P010 stores each Y component in a 16-bit value, with the
bottom 6 bits ignored. So I think cpp here should be 2.

Cheers,
Daniel

Re: [PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format

[Ayaka]

從我的 iPad 傳送

> Daniel Stone <daniel@fooishbar.org> 於 2017年1月5日 上午1:02 寫道：
> 
> Hi Randy,
> 
>> On 4 January 2017 at 16:29, Randy Li <ayaka@soulik.info> wrote:
>> index 90d2cc8..23c8e99 100644
>> --- a/drivers/gpu/drm/drm_fourcc.c
>> +++ b/drivers/gpu/drm/drm_fourcc.c
>> @@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
>>                { .format = DRM_FORMAT_UYVY,            .depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>>                { .format = DRM_FORMAT_VYUY,            .depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>>                { .format = DRM_FORMAT_AYUV,            .depth = 0,  .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
>> +               /* FIXME a pixel in Y for P010 is 10 bits */
>> +               { .format = DRM_FORMAT_P010,            .depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
> 
> It seems like P010 stores each Y component in a 16-bit value, with the
> bottom 6 bits ignored. So I think cpp here should be 2.
No, the rest bits are used to store the next pixel. The P010 is just a 10 bits color depth pixel format.
> 
> Cheers,
> Daniel

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

[Sakari Ailus]

Hi Randy,

Thanks for the update.

On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:
> The formats added by this patch are:
> 	V4L2_PIX_FMT_P010
> 	V4L2_PIX_FMT_P010M
> 	V4L2_PIX_FMT_P016
> 	V4L2_PIX_FMT_P016M
> 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 10 bits format for
> profile_10 HEVC/AVC video.
> 
> Signed-off-by: Randy Li <ayaka@soulik.info>
> 
> v4l2
> ---
>  Documentation/media/uapi/v4l/pixfmt-p010.rst  |  86 ++++++++++++++++
>  Documentation/media/uapi/v4l/pixfmt-p010m.rst |  94 ++++++++++++++++++
>  Documentation/media/uapi/v4l/pixfmt-p016.rst  | 126 ++++++++++++++++++++++++
>  Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 ++++++++++++++++++++++++++

You need to include the formats in pixfmt.rst in order to compile the
documentation.

$ make htmldocs

And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html .

In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme
.

Regarding P010 and the rest --- I'm fine with that, considering also that
NV12 was never a great name for a format...

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

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

[ayaka]

On 01/05/2017 06:30 PM, Sakari Ailus wrote:
> Hi Randy,
>
> Thanks for the update.
>
> On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:
>> The formats added by this patch are:
>> 	V4L2_PIX_FMT_P010
>> 	V4L2_PIX_FMT_P010M
>> 	V4L2_PIX_FMT_P016
>> 	V4L2_PIX_FMT_P016M
>> 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 10 bits format for
>> profile_10 HEVC/AVC video.
>>
>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>
>> v4l2
>> ---
>>   Documentation/media/uapi/v4l/pixfmt-p010.rst  |  86 ++++++++++++++++
>>   Documentation/media/uapi/v4l/pixfmt-p010m.rst |  94 ++++++++++++++++++
>>   Documentation/media/uapi/v4l/pixfmt-p016.rst  | 126 ++++++++++++++++++++++++
>>   Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 ++++++++++++++++++++++++++
> You need to include the formats in pixfmt.rst in order to compile the
> documentation.
>
> $ make htmldocs
>
> And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html .
>
> In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme
> .
OK, I would fix them in new version.
The view of byte order for P010 serial is left empty, it is a little 
hard for me to use flat-table to draw them. Is there possible to use 
something like latex to do this job?
>
> Regarding P010 and the rest --- I'm fine with that, considering also that
> NV12 was never a great name for a format...
>

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

[Sakari Ailus]

Hi Randy,

On Thu, Jan 05, 2017 at 11:22:26PM +0800, ayaka wrote:
> 
> 
> On 01/05/2017 06:30 PM, Sakari Ailus wrote:
> >Hi Randy,
> >
> >Thanks for the update.
> >
> >On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:
> >>The formats added by this patch are:
> >>	V4L2_PIX_FMT_P010
> >>	V4L2_PIX_FMT_P010M
> >>	V4L2_PIX_FMT_P016
> >>	V4L2_PIX_FMT_P016M
> >>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 10 bits format for
> >>profile_10 HEVC/AVC video.
> >>
> >>Signed-off-by: Randy Li <ayaka@soulik.info>
> >>
> >>v4l2
> >>---
> >>  Documentation/media/uapi/v4l/pixfmt-p010.rst  |  86 ++++++++++++++++
> >>  Documentation/media/uapi/v4l/pixfmt-p010m.rst |  94 ++++++++++++++++++
> >>  Documentation/media/uapi/v4l/pixfmt-p016.rst  | 126 ++++++++++++++++++++++++
> >>  Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 ++++++++++++++++++++++++++
> >You need to include the formats in pixfmt.rst in order to compile the
> >documentation.
> >
> >$ make htmldocs
> >
> >And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html .
> >
> >In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme
> >.
> OK, I would fix them in new version.
> The view of byte order for P010 serial is left empty, it is a little hard
> for me to use flat-table to draw them. Is there possible to use something
> like latex to do this job?

Hmm. Not as far as I know. We recently switched from DocBook mostly due to
ReST being more simple to use AFAIU. I think LaTeX output could be produced
ReST, that might not be very helpful here though.

> >
> >Regarding P010 and the rest --- I'm fine with that, considering also that
> >NV12 was never a great name for a format...
> >
> 

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

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

[Mauro Carvalho Chehab]

Em Thu, 5 Jan 2017 20:27:17 +0200
Sakari Ailus <sakari.ailus@iki.fi> escreveu:

> Hi Randy,
> 
> On Thu, Jan 05, 2017 at 11:22:26PM +0800, ayaka wrote:
> > 
> > 
> > On 01/05/2017 06:30 PM, Sakari Ailus wrote:  
> > >Hi Randy,
> > >
> > >Thanks for the update.
> > >
> > >On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:  
> > >>The formats added by this patch are:
> > >>	V4L2_PIX_FMT_P010
> > >>	V4L2_PIX_FMT_P010M
> > >>	V4L2_PIX_FMT_P016
> > >>	V4L2_PIX_FMT_P016M
> > >>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 10 bits format for
> > >>profile_10 HEVC/AVC video.
> > >>
> > >>Signed-off-by: Randy Li <ayaka@soulik.info>
> > >>
> > >>v4l2
> > >>---
> > >>  Documentation/media/uapi/v4l/pixfmt-p010.rst  |  86 ++++++++++++++++
> > >>  Documentation/media/uapi/v4l/pixfmt-p010m.rst |  94 ++++++++++++++++++
> > >>  Documentation/media/uapi/v4l/pixfmt-p016.rst  | 126 ++++++++++++++++++++++++
> > >>  Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 ++++++++++++++++++++++++++  
> > >You need to include the formats in pixfmt.rst in order to compile the
> > >documentation.
> > >
> > >$ make htmldocs
> > >
> > >And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html .
> > >
> > >In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme
> > >.  
> > OK, I would fix them in new version.
> > The view of byte order for P010 serial is left empty, it is a little hard
> > for me to use flat-table to draw them. Is there possible to use something
> > like latex to do this job?  
> 
> Hmm. Not as far as I know. We recently switched from DocBook mostly due to
> ReST being more simple to use AFAIU. I think LaTeX output could be produced
> ReST, that might not be very helpful here though.

No, you can't use LaTeX, as it won't be properly displayed on all output
formats. There are a few options to define tables in ReST, but we prefer
using flat-table because the other formats are harder to maintain at the
V4L2 uAPI documentation.

Just one note about this series: it won't be merged upstream until
someone adds a driver needing those pixel formats.

Regards,
Mauro


Thanks,
Mauro

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

[Ayaka]

從我的 iPad 傳送

> Mauro Carvalho Chehab <mchehab@s-opensource.com> 於 2017年2月3日 下午10:04 寫道：
> 
> Em Thu, 5 Jan 2017 20:27:17 +0200
> Sakari Ailus <sakari.ailus@iki.fi> escreveu:
> 
>> Hi Randy,
>> 
>>> On Thu, Jan 05, 2017 at 11:22:26PM +0800, ayaka wrote:
>>> 
>>> 
>>>> On 01/05/2017 06:30 PM, Sakari Ailus wrote:  
>>>> Hi Randy,
>>>> 
>>>> Thanks for the update.
>>>> 
>>>>> On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:  
>>>>> The formats added by this patch are:
>>>>>    V4L2_PIX_FMT_P010
>>>>>    V4L2_PIX_FMT_P010M
>>>>>    V4L2_PIX_FMT_P016
>>>>>    V4L2_PIX_FMT_P016M
>>>>> 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 10 bits format for
>>>>> profile_10 HEVC/AVC video.
>>>>> 
>>>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>>>> 
>>>>> v4l2
>>>>> ---
>>>>> Documentation/media/uapi/v4l/pixfmt-p010.rst  |  86 ++++++++++++++++
>>>>> Documentation/media/uapi/v4l/pixfmt-p010m.rst |  94 ++++++++++++++++++
>>>>> Documentation/media/uapi/v4l/pixfmt-p016.rst  | 126 ++++++++++++++++++++++++
>>>>> Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 ++++++++++++++++++++++++++  
>>>> You need to include the formats in pixfmt.rst in order to compile the
>>>> documentation.
>>>> 
>>>> $ make htmldocs
>>>> 
>>>> And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html .
>>>> 
>>>> In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme
>>>> .  
>>> OK, I would fix them in new version.
>>> The view of byte order for P010 serial is left empty, it is a little hard
>>> for me to use flat-table to draw them. Is there possible to use something
>>> like latex to do this job?  
>> 
>> Hmm. Not as far as I know. We recently switched from DocBook mostly due to
>> ReST being more simple to use AFAIU. I think LaTeX output could be produced
>> ReST, that might not be very helpful here though.
> 
> No, you can't use LaTeX, as it won't be properly displayed on all output
> formats. There are a few options to define tables in ReST, but we prefer
> using flat-table because the other formats are harder to maintain at the
> V4L2 uAPI documentation.
> 
> Just one note about this series: it won't be merged upstream until
> someone adds a driver needing those pixel formats.
> 
I made a mistake, the pixel format I want is not P010, I would post a new patch for that.
> Regards,
> Mauro
> 
> 
> Thanks,
> Mauro