From: Ezequiel Garcia <ezequiel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> To: Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>, linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>, Nicolas Dufresne <nicolas.dufresne-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>, Tomasz Figa <tfiga-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>, Miouyouyou <myy-tmjzNUIc0P1+EYZtW95mkQ@public.gmane.org>, kernel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org, Shunqian Zheng <zhengsq-TNX95d0MmH7DzftRWevZcw@public.gmane.org> Subject: Re: [PATCH v5 5/6] media: Add controls for JPEG quantization tables Date: Mon, 10 Sep 2018 10:25:10 -0300 [thread overview] Message-ID: <710d4e77de63b46e6ffd440c9c98ca9af133117f.camel@collabora.com> (raw) In-Reply-To: <718d8a73-008a-a610-d090-91cc54a992ad-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> Hi Hans, Thanks for the review. On Mon, 2018-09-10 at 14:42 +0200, Hans Verkuil wrote: > On 09/06/2018 12:00 AM, Ezequiel Garcia wrote: > > From: Shunqian Zheng <zhengsq-TNX95d0MmH7DzftRWevZcw@public.gmane.org> > > > > Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace > > configure the JPEG quantization tables. > > > > Signed-off-by: Shunqian Zheng <zhengsq-TNX95d0MmH7DzftRWevZcw@public.gmane.org> > > Signed-off-by: Ezequiel Garcia <ezequiel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> > > --- > > .../media/uapi/v4l/extended-controls.rst | 31 +++++++++++++++++++ > > .../media/videodev2.h.rst.exceptions | 1 + > > drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++++++ > > include/uapi/linux/v4l2-controls.h | 12 +++++++ > > include/uapi/linux/videodev2.h | 1 + > > 5 files changed, 55 insertions(+) > > > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst > > index 9f7312bf3365..1335d27d30f3 100644 > > --- a/Documentation/media/uapi/v4l/extended-controls.rst > > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > > @@ -3354,7 +3354,38 @@ JPEG Control IDs > > Specify which JPEG markers are included in compressed stream. This > > control is valid only for encoders. > > > > +.. _jpeg-quant-tables-control: > > > > +``V4L2_CID_JPEG_QUANTIZATION (struct)`` > > + Specifies the luma and chroma quantization matrices for encoding > > + or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The :ref:`itu-t81` > > + specification allows 8-bit quantization coefficients for > > + baseline profile images, and 8-bit or 16-bit for extended profile > > + images. Supporting or not 16-bit precision coefficients is driver-specific. > > + Coefficients must be set in JPEG zigzag scan order. > > + > > + > > +.. c:type:: struct v4l2_ctrl_jpeg_quantization > > + > > +.. cssclass:: longtable > > + > > +.. flat-table:: struct v4l2_ctrl_jpeg_quantization > > + :header-rows: 0 > > + :stub-columns: 0 > > + :widths: 1 1 2 > > + > > + * - __u8 > > + - ``precision`` > > + - Specifies the coefficient precision. User shall set 0 > > + for 8-bit, and 1 for 16-bit. > > So does specifying 1 here switch the HW encoder to use extended profile? > What if the HW only supports baseline? The rockchip driver doesn't appear > to check the precision field at all... > The driver is missing to check that, when the user sets this control. > I think this needs a bit more thought. > > I am not at all sure that this is the right place for the precision field. > This is really about JPEG profiles, so I would kind of expect a JPEG PROFILE > control (just like other codec profiles), or possibly a new pixelformat for > extended profiles. > > And based on that the driver would interpret these matrix values as 8 or > 16 bits. > Right, the JPEG profile control is definitely needed. I haven't add it because it wouldn't be used, since this VPU can only do baseline. However, the problem is that some JPEGs in the wild have with 8-bit data and 16-bit quantization coefficients, as per [1] and [2]: [1] https://github.com/martinhath/jpeg-rust/issues/1 [2] https://github.com/libjpeg-turbo/libjpeg-turbo/pull/90 So, in order to support decoding of these images, I've added the precision field to the quantization control. The user would be able to set a baseline or extended profile thru a (future) profile control, and if 16-bit tables are found, and if the hardware supports them, the driver would be able to support them. Another option, which might be even better, is have explicit baseline and extended quantization tables controls, e.g.: V4L2_CID_JPEG_QUANT and V4L2_CID_JPEG_EXT_QUANT. Thanks, Ezequiel
WARNING: multiple messages have this Message-ID (diff)
From: Ezequiel Garcia <ezequiel@collabora.com> To: Hans Verkuil <hverkuil@xs4all.nl>, linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org Cc: Hans Verkuil <hans.verkuil@cisco.com>, kernel@collabora.com, Nicolas Dufresne <nicolas.dufresne@collabora.com>, Tomasz Figa <tfiga@chromium.org>, Heiko Stuebner <heiko@sntech.de>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Miouyouyou <myy@miouyouyou.fr>, Shunqian Zheng <zhengsq@rock-chips.com> Subject: Re: [PATCH v5 5/6] media: Add controls for JPEG quantization tables Date: Mon, 10 Sep 2018 10:25:10 -0300 [thread overview] Message-ID: <710d4e77de63b46e6ffd440c9c98ca9af133117f.camel@collabora.com> (raw) In-Reply-To: <718d8a73-008a-a610-d090-91cc54a992ad@xs4all.nl> Hi Hans, Thanks for the review. On Mon, 2018-09-10 at 14:42 +0200, Hans Verkuil wrote: > On 09/06/2018 12:00 AM, Ezequiel Garcia wrote: > > From: Shunqian Zheng <zhengsq@rock-chips.com> > > > > Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace > > configure the JPEG quantization tables. > > > > Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> > > Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> > > --- > > .../media/uapi/v4l/extended-controls.rst | 31 +++++++++++++++++++ > > .../media/videodev2.h.rst.exceptions | 1 + > > drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++++++ > > include/uapi/linux/v4l2-controls.h | 12 +++++++ > > include/uapi/linux/videodev2.h | 1 + > > 5 files changed, 55 insertions(+) > > > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst > > index 9f7312bf3365..1335d27d30f3 100644 > > --- a/Documentation/media/uapi/v4l/extended-controls.rst > > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > > @@ -3354,7 +3354,38 @@ JPEG Control IDs > > Specify which JPEG markers are included in compressed stream. This > > control is valid only for encoders. > > > > +.. _jpeg-quant-tables-control: > > > > +``V4L2_CID_JPEG_QUANTIZATION (struct)`` > > + Specifies the luma and chroma quantization matrices for encoding > > + or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The :ref:`itu-t81` > > + specification allows 8-bit quantization coefficients for > > + baseline profile images, and 8-bit or 16-bit for extended profile > > + images. Supporting or not 16-bit precision coefficients is driver-specific. > > + Coefficients must be set in JPEG zigzag scan order. > > + > > + > > +.. c:type:: struct v4l2_ctrl_jpeg_quantization > > + > > +.. cssclass:: longtable > > + > > +.. flat-table:: struct v4l2_ctrl_jpeg_quantization > > + :header-rows: 0 > > + :stub-columns: 0 > > + :widths: 1 1 2 > > + > > + * - __u8 > > + - ``precision`` > > + - Specifies the coefficient precision. User shall set 0 > > + for 8-bit, and 1 for 16-bit. > > So does specifying 1 here switch the HW encoder to use extended profile? > What if the HW only supports baseline? The rockchip driver doesn't appear > to check the precision field at all... > The driver is missing to check that, when the user sets this control. > I think this needs a bit more thought. > > I am not at all sure that this is the right place for the precision field. > This is really about JPEG profiles, so I would kind of expect a JPEG PROFILE > control (just like other codec profiles), or possibly a new pixelformat for > extended profiles. > > And based on that the driver would interpret these matrix values as 8 or > 16 bits. > Right, the JPEG profile control is definitely needed. I haven't add it because it wouldn't be used, since this VPU can only do baseline. However, the problem is that some JPEGs in the wild have with 8-bit data and 16-bit quantization coefficients, as per [1] and [2]: [1] https://github.com/martinhath/jpeg-rust/issues/1 [2] https://github.com/libjpeg-turbo/libjpeg-turbo/pull/90 So, in order to support decoding of these images, I've added the precision field to the quantization control. The user would be able to set a baseline or extended profile thru a (future) profile control, and if 16-bit tables are found, and if the hardware supports them, the driver would be able to support them. Another option, which might be even better, is have explicit baseline and extended quantization tables controls, e.g.: V4L2_CID_JPEG_QUANT and V4L2_CID_JPEG_EXT_QUANT. Thanks, Ezequiel
next prev parent reply other threads:[~2018-09-10 13:25 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-05 22:00 [PATCH v5 0/6] Add Rockchip VPU JPEG encoder Ezequiel Garcia 2018-09-05 22:00 ` Ezequiel Garcia [not found] ` <20180905220011.16612-1-ezequiel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> 2018-09-05 22:00 ` [PATCH v5 1/6] dt-bindings: Document the Rockchip VPU bindings Ezequiel Garcia 2018-09-05 22:00 ` Ezequiel Garcia 2018-09-05 22:00 ` [PATCH v5 2/6] ARM: dts: rockchip: add VPU device node for RK3288 Ezequiel Garcia 2018-09-05 22:00 ` Ezequiel Garcia 2018-09-05 22:00 ` [PATCH v5 3/6] arm64: dts: rockchip: add VPU device node for RK3399 Ezequiel Garcia 2018-09-05 22:00 ` Ezequiel Garcia 2018-09-05 22:00 ` [PATCH v5 4/6] media: Add JPEG_RAW format Ezequiel Garcia 2018-09-05 22:00 ` Ezequiel Garcia 2018-09-05 22:00 ` [PATCH v5 5/6] media: Add controls for JPEG quantization tables Ezequiel Garcia 2018-09-05 22:00 ` Ezequiel Garcia [not found] ` <20180905220011.16612-6-ezequiel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> 2018-09-10 12:42 ` Hans Verkuil 2018-09-10 12:42 ` Hans Verkuil [not found] ` <718d8a73-008a-a610-d090-91cc54a992ad-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> 2018-09-10 13:25 ` Ezequiel Garcia [this message] 2018-09-10 13:25 ` Ezequiel Garcia [not found] ` <710d4e77de63b46e6ffd440c9c98ca9af133117f.camel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> 2018-09-15 16:48 ` Paul Kocialkowski 2018-09-15 16:48 ` Paul Kocialkowski [not found] ` <928a021c1e402f99eadd20e00aa5ec0cc218edbd.camel-W9ppeneeCTY@public.gmane.org> 2018-09-19 4:21 ` Tomasz Figa 2018-09-19 4:21 ` Tomasz Figa 2018-09-13 12:14 ` Paul Kocialkowski 2018-09-13 12:14 ` Paul Kocialkowski [not found] ` <e7126e89d8984eb93216ec75c83ce1fc5afc437d.camel-W9ppeneeCTY@public.gmane.org> 2018-09-13 19:40 ` Paul Kocialkowski 2018-09-13 19:40 ` Paul Kocialkowski 2018-09-19 4:28 ` Tomasz Figa 2018-09-19 4:28 ` Tomasz Figa [not found] ` <CAAFQd5Bir0uMsaJPHdgQDvcYHpxZ4sUSn10OPpRXcnn-THUx2A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-10-12 20:00 ` Paul Kocialkowski 2018-10-12 20:00 ` Paul Kocialkowski [not found] ` <2878c8fa36f6e775079f53ba79518a53e1ea6bc5.camel-W9ppeneeCTY@public.gmane.org> 2018-10-15 16:07 ` Ezequiel Garcia 2018-10-15 16:07 ` Ezequiel Garcia 2018-09-05 22:00 ` [PATCH v5 6/6] media: add Rockchip VPU JPEG encoder driver Ezequiel Garcia 2018-09-05 22:00 ` Ezequiel Garcia
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=710d4e77de63b46e6ffd440c9c98ca9af133117f.camel@collabora.com \ --to=ezequiel-zgy8ohtn/8qb+jhodadfcq@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org \ --cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \ --cc=hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org \ --cc=kernel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org \ --cc=linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \ --cc=myy-tmjzNUIc0P1+EYZtW95mkQ@public.gmane.org \ --cc=nicolas.dufresne-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org \ --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=tfiga-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \ --cc=zhengsq-TNX95d0MmH7DzftRWevZcw@public.gmane.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.