From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
To: Mirela Rabulea <mirela.rabulea@nxp.com>,
"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
"mchehab@kernel.org" <mchehab@kernel.org>,
"shawnguo@kernel.org" <shawnguo@kernel.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>
Cc: dl-linux-imx <linux-imx@nxp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"laurent.pinchart+renesas@ideasonboard.com"
<laurent.pinchart+renesas@ideasonboard.com>,
Aisheng Dong <aisheng.dong@nxp.com>,
Laurentiu Palcu <laurentiu.palcu@nxp.com>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
Robert Chiras <robert.chiras@nxp.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"paul.kocialkowski@bootlin.com" <paul.kocialkowski@bootlin.com>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"niklas.soderlund+renesas@ragnatech.se"
<niklas.soderlund+renesas@ragnatech.se>,
Daniel Baluta <daniel.baluta@nxp.com>,
"dafna.hirschfeld@collabora.com" <dafna.hirschfeld@collabora.com>,
"ezequiel@collabora.com" <ezequiel@collabora.com>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>
Subject: Re: [EXT] Re: [PATCH v7 3/9] media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder
Date: Wed, 10 Mar 2021 13:40:17 +0100 [thread overview]
Message-ID: <193d220b-8086-d968-9038-e4c435df0549@xs4all.nl> (raw)
In-Reply-To: <72006a57d2501cf85da181d67ed4727f12528eb9.camel@nxp.com>
On 10/03/2021 13:33, Mirela Rabulea wrote:
> Hi Hans,
>
> On Thu, 2021-03-04 at 14:03 +0100, Hans Verkuil wrote:
>> Caution: EXT Email
>>
>> On 22/02/2021 20:09, Mirela Rabulea wrote:
>>> Hi Hans,
>>> appologies for my late response, please see below 2 comments.
>>
>> Replies below:
>>
>>>
>>> On Tue, 2021-01-19 at 11:31 +0100, Hans Verkuil wrote:
>>>> Caution: EXT Email
>>>>
>>>> On 11/01/2021 20:28, Mirela Rabulea wrote:
>>>>> From: Mirela Rabulea <mirela.rabulea@nxp.com>
>>>>>
>>>>> V4L2 driver for the JPEG encoder/decoder from i.MX8QXP/i.MX8QM
>>>>> application
>>>>> processors.
>>>>> The multi-planar buffers API is used.
>>>>>
>>>>> Baseline and extended sequential jpeg decoding is supported.
>>>>> Progressive jpeg decoding is not supported by the IP.
>>>>> Supports encode and decode of various formats:
>>>>> YUV444, YUV422, YUV420, RGB, ARGB, Gray
>>>>> YUV420 is the only multi-planar format supported.
>>>>> Minimum resolution is 64 x 64, maximum 8192 x 8192.
>>>>> The alignment requirements for the resolution depend on the
>>>>> format,
>>>>> multiple of 16 resolutions should work for all formats.
>>>>>
>>>>> v4l2-compliance tests are passing, including the
>>>>> streaming tests, "v4l2-compliance -s"
>>>>>
>>>>> Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
>>>>> ---
>>>>> Changes in v7:
>>>>> Add print_mxc_buf() to replace print_buf_preview() and
>>>>> print_nbuf_to_eoi(),
>>>>> and inside, use the print_hex_dump() from printk.h, also,
>>>>> print
>>>>> all the planes.
>>>>>
>>>>> drivers/media/platform/Kconfig | 2 +
>>>>> drivers/media/platform/Makefile | 1 +
>>>>> drivers/media/platform/imx-jpeg/Kconfig | 10 +
>>>>> drivers/media/platform/imx-jpeg/Makefile | 3 +
>>>>> drivers/media/platform/imx-jpeg/mxc-jpeg-hw.c | 168 ++
>>>>> drivers/media/platform/imx-jpeg/mxc-jpeg-hw.h | 140 +
>>>>> drivers/media/platform/imx-jpeg/mxc-jpeg.c | 2289
>>>>> +++++++++++++++++
>>>>> drivers/media/platform/imx-jpeg/mxc-jpeg.h | 184 ++
>>>>> 8 files changed, 2797 insertions(+)
>>>>> create mode 100644 drivers/media/platform/imx-jpeg/Kconfig
>>>>> create mode 100644 drivers/media/platform/imx-jpeg/Makefile
>>>>> create mode 100644 drivers/media/platform/imx-jpeg/mxc-jpeg-
>>>>> hw.c
>>>>> create mode 100644 drivers/media/platform/imx-jpeg/mxc-jpeg-
>>>>> hw.h
>>>>> create mode 100644 drivers/media/platform/imx-jpeg/mxc-jpeg.c
>>>>> create mode 100644 drivers/media/platform/imx-jpeg/mxc-jpeg.h
>>>>
>>>> One high-level comment: why introduce the driver in patch 3/9 and
>>>> then
>>>> change it again in 9/9? I would very much prefer to have just a
>>>> single
>>>> patch that adds this driver, i.e. merge patch 3 and 9 into a
>>>> single
>>>> patch.
>>>
>>> I can squash patch 9 into patch 3, but please note that patch 9
>>> depends
>>> on jpeg helper patches 6,7,8, so these patches will also have to
>>> move
>>> before patch 3. Let me know yout thought and I'll do this in v9, in
>>> v8
>>> version I only addressed the rest of your feedback and some more
>>> from
>>> Philipp.
>>
>> Yes, just move the jpeg helper to earlier in the patch series.
>>
>>>
>>>>
>>
>> <snip>
>>
>>>>> + /* fix colorspace information to sRGB for both output &
>>>>> capture */
>>>>> + pix_mp->colorspace = V4L2_COLORSPACE_SRGB;
>>>>> + pix_mp->ycbcr_enc = V4L2_YCBCR_ENC_601;
>>>>> + pix_mp->xfer_func = V4L2_XFER_FUNC_SRGB;
>>>>> + pix_mp->quantization = V4L2_QUANTIZATION_FULL_RANGE;
>>>>
>>>> So YUV formats are expected to be full range as well? Both when
>>>> encoding
>>>> and decoding?
>>>
>>> I set the colorspace information like that based on this comment:
>>> /*
>>> * Effectively shorthand for V4L2_COLORSPACE_SRGB,
>>> V4L2_YCBCR_ENC_601
>>> * and V4L2_QUANTIZATION_FULL_RANGE. To be used for (Motion-
>>> )JPEG.
>>> */
>>> V4L2_COLORSPACE_JPEG = 7,
>>>
>>
>> Inside a JPEG the YUV quantization is using full range. But when you
>> *decode* a JPEG the YUV quantization in the raw decoded image is
>> normally limited range again (the default for YUV).
>>
>> It depends on what this decoder does: most will decode to limited
>> range YUV, some decode to full range YUV (in which case this code
>> would be
>> correct), and some support both.
>
> Experimentally, I saw the decoder outputs full-range values, but I was
> not sure about limited-range support, so I asked our IP owner, and I
> got this answer:
> "The decoder does not alter the range of the data in any way.
> It outputs the same full or limited range data that was given to the
> encoder."
>
> So, surely our encoder/decoder cannot change the range of the samples,
> but it could process both full or half range.
> I was thinking about a possibility to allow a half-range streams
> scenario (half range raw format -> encoder -> jpeg with half range???
> -> decoder -> half range raw format).
> That could be achieved by allowing user to choose (specify) the
> quantization for the output stream, and the driver would set the same
> for the capture stream, but this would result in a JPEG with half range
> for the capture stream.
> So, you mentioned inside JPEG the YUV quantization is using full range,
> experience confirms it (I decoded a jpeg produced with gimp and one
> with ms-paint, and I saw full range values), and v4l2-compliance fails
> if the pixel format is JPEG and quantization is not full.
> I'm not sure if the standard allows half-range JPEG (it would be a
> subset of full-range, so theoretically possible).
>
> So, I will just add a comment to clarify the mxc-jpeg driver will
> always use full-range.
>
> The mxc-jpeg driver will not support CSC, therefor it is not setting
> V4L2_FMT_FLAG_CSC_COLORSPACE in v4l2_fmtdesc during enumeration.
> So, the application cannot request a specific colorspace for the
> capture stream. No change needed here.
>
> Let me know if this sounds ok, and I'll send v9 with the added coment
> and the squash.
Yes, just add a comment that the JPEG codec always uses full range YUV
for the uncompressed frames.
Regards,
Hans
>
> Thanks,
> Mirela
>
>>
>> In the latter case you want to support the V4L2_PIX_FMT_FLAG_SET_CSC
>> flag:
>>
>>
>
next prev parent reply other threads:[~2021-03-10 12:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 19:28 [PATCH v7 0/9] Add V4L2 driver for i.MX8 JPEG Encoder/Decoder Mirela Rabulea
2021-01-11 19:28 ` [PATCH v7 1/9] media: v4l: Add packed YUV444 24bpp pixel format Mirela Rabulea
2021-01-11 19:28 ` [PATCH v7 2/9] media: dt-bindings: Add bindings for i.MX8QXP/QM JPEG driver Mirela Rabulea
2021-01-11 19:28 ` [PATCH v7 3/9] media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder Mirela Rabulea
2021-01-19 10:31 ` Hans Verkuil
2021-02-22 19:09 ` [EXT] " Mirela Rabulea
2021-03-04 13:03 ` Hans Verkuil
2021-03-10 12:33 ` Mirela Rabulea
2021-03-10 12:40 ` Hans Verkuil [this message]
2021-01-11 19:28 ` [PATCH v7 4/9] arm64: dts: imx8qxp: Add jpeg encoder/decoder nodes Mirela Rabulea
2021-01-11 19:28 ` [PATCH v7 5/9] Add maintainer for IMX jpeg v4l2 driver Mirela Rabulea
2021-01-11 19:28 ` [PATCH v7 6/9] media: Add parsing for APP14 data segment in jpeg helpers Mirela Rabulea
2021-01-12 14:58 ` Philipp Zabel
2021-01-11 19:28 ` [PATCH v7 7/9] media: Quit parsing stream if doesn't start with SOI Mirela Rabulea
2021-01-11 19:28 ` [PATCH v7 8/9] media: Avoid parsing quantization and huffman tables Mirela Rabulea
2021-01-11 19:28 ` [PATCH v7 9/9] media: imx-jpeg: Use v4l2 jpeg helpers in mxc-jpeg Mirela Rabulea
2021-01-12 15:00 ` Philipp Zabel
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=193d220b-8086-d968-9038-e4c435df0549@xs4all.nl \
--to=hverkuil-cisco@xs4all.nl \
--cc=aisheng.dong@nxp.com \
--cc=dafna.hirschfeld@collabora.com \
--cc=daniel.baluta@nxp.com \
--cc=devicetree@vger.kernel.org \
--cc=ezequiel@collabora.com \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=laurentiu.palcu@nxp.com \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mchehab@kernel.org \
--cc=mirela.rabulea@nxp.com \
--cc=niklas.soderlund+renesas@ragnatech.se \
--cc=p.zabel@pengutronix.de \
--cc=paul.kocialkowski@bootlin.com \
--cc=robert.chiras@nxp.com \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).