From: Adrian Ratiu <adrian.ratiu@collabora.com>
To: Philipp Zabel <p.zabel@pengutronix.de>, linux-media@vger.kernel.org
Cc: Ezequiel Garcia <ezequiel@collabora.com>,
Mirela Rabulea <mirela.rabulea@nxp.com>,
kernel@pengutronix.de, Adrian Ratiu <adrian.ratiu@collabora.com>,
Tim Harvey <tharvey@gateworks.com>
Subject: Re: [PATCH v2 0/6] v4l2 JPEG helpers and CODA960 JPEG decoder
Date: Sun, 22 Mar 2020 23:41:22 +0200 [thread overview]
Message-ID: <87eetkgj99.fsf@collabora.com> (raw)
In-Reply-To: <20200318183536.15779-1-p.zabel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
Hi Philipp,
Tested-by: Adrian Ratiu <adrian.ratiu@collabora.com>
Awesome work! I'm testing this series with the following two
patches applied on top to extend functionality a bit. Please
feel free to include these changes in your next version if
you plan one.
During testing a weird bug was discovered in both v1 and v2
causing color degradation in raw YUV decoded images. Will
send test files and exact reproduction steps in another mail.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-media-coda-jpeg-support-optimized-huffman-tables.patch --]
[-- Type: text/x-patch, Size: 2244 bytes --]
From 13e8894cad8a41391bb417f1c5f6b6a16edd6695 Mon Sep 17 00:00:00 2001
From: Adrian Ratiu <adrian.ratiu@collabora.com>
Date: Wed, 18 Mar 2020 09:07:22 +0200
Subject: [PATCH 1/2] media: coda: jpeg: support optimized huffman tables
Each jpeg can have the huffman tables optimized for its specific content
meaning that the table lenghts and values don't match the standard table
of substitutions so there's no reason to hardcode and expect the sandard
lenghts, otherwise we just end up rejecting optimized jpegs altogether.
Tested on CODA960.
Change-Id: I8763801dfac944bf08c4ae6fbcd94ce8de2bd432
---
drivers/media/platform/coda/coda-jpeg.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/coda/coda-jpeg.c b/drivers/media/platform/coda/coda-jpeg.c
index 6a11b64efb6b..162ba28a6b95 100644
--- a/drivers/media/platform/coda/coda-jpeg.c
+++ b/drivers/media/platform/coda/coda-jpeg.c
@@ -343,7 +343,8 @@ int coda_jpeg_decode_header(struct coda_ctx *ctx, struct vb2_buffer *vb)
v4l2_err(&dev->v4l2_dev, "missing Huffman table\n");
return -EINVAL;
}
- if (huffman_tables[i].length != ((i & 2) ? 178 : 28)) {
+ if (huffman_tables[i].length < 17 ||
+ huffman_tables[i].length > 178) {
v4l2_err(&dev->v4l2_dev,
"invalid Huffman table %d length: %zu\n",
i, huffman_tables[i].length);
@@ -357,10 +358,12 @@ int coda_jpeg_decode_header(struct coda_ctx *ctx, struct vb2_buffer *vb)
return -ENOMEM;
ctx->params.jpeg_huff_tab = huff_tab;
}
- memcpy(huff_tab->luma_dc, huffman_tables[0].start, 16 + 12);
- memcpy(huff_tab->chroma_dc, huffman_tables[1].start, 16 + 12);
- memcpy(huff_tab->luma_ac, huffman_tables[2].start, 16 + 162);
- memcpy(huff_tab->chroma_ac, huffman_tables[3].start, 16 + 162);
+
+ memset(huff_tab, 0, sizeof(*huff_tab));
+ memcpy(huff_tab->luma_dc, huffman_tables[0].start, huffman_tables[0].length);
+ memcpy(huff_tab->chroma_dc, huffman_tables[1].start, huffman_tables[1].length);
+ memcpy(huff_tab->luma_ac, huffman_tables[2].start, huffman_tables[2].length);
+ memcpy(huff_tab->chroma_ac, huffman_tables[3].start, huffman_tables[3].length);
/* check scan header */
for (i = 0; i < scan_header.num_components; i++) {
--
2.25.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-media-coda-be-more-flexible-wrt-jpeg-dimensions.patch --]
[-- Type: text/x-patch, Size: 1462 bytes --]
From bf6e82057c7423dfa96ac76d75547ce6dc5f1caf Mon Sep 17 00:00:00 2001
From: Adrian Ratiu <adrian.ratiu@collabora.com>
Date: Sun, 22 Mar 2020 22:33:13 +0200
Subject: [PATCH 2/2] media: coda: be more flexible wrt jpeg dimensions
Don't require jpeg dimensions to exactly match the format dimensions,
so we are able to decode and display a wider range jpegs instead of
outright rejecting ones like the following:
coda 2040000.vpu: dimensions don't match format: 700x523
coda 2040000.vpu: failed to decode JPEG header: -22
Change-Id: I385082e43c896c81ea4aa09c49d87e9347ec4058
---
drivers/media/platform/coda/coda-jpeg.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/coda/coda-jpeg.c b/drivers/media/platform/coda/coda-jpeg.c
index 162ba28a6b95..8427d7a37bed 100644
--- a/drivers/media/platform/coda/coda-jpeg.c
+++ b/drivers/media/platform/coda/coda-jpeg.c
@@ -302,10 +302,10 @@ int coda_jpeg_decode_header(struct coda_ctx *ctx, struct vb2_buffer *vb)
}
q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
- if (header.frame.height != q_data_src->height ||
- header.frame.width != q_data_src->width) {
+ if (header.frame.height > q_data_src->height ||
+ header.frame.width > q_data_src->width) {
v4l2_err(&dev->v4l2_dev,
- "dimensions don't match format: %dx%d\n",
+ "dimensions don't fit: %dx%d\n",
header.frame.width, header.frame.height);
return -EINVAL;
}
--
2.25.2
[-- Attachment #4: Type: text/plain, Size: 2162 bytes --]
Thanks,
Adrian
On Wed, 18 Mar 2020, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Hi,
>
> the JPEG header parser is updated to accept up to four components,
> baseline and extended-sequential DCT encoded images, 8-bit and 12-bit
> precision, as well as 8-bit and 16-bit quantization tables. As a
> consequence, all drivers will have to check the number of components,
> precision, and quantization table lengths.
>
> I have not yet added support parsing the Adobe APP14 headers to
> determine the color encoding, as it is unclear to me how it could be
> used to signal RGBA components - for 4-component images it is defined
> to disambiguate between CMYK and YCCK encodings. This is implemented
> in libjpeg.
> Patching the header data in place to normalize the component identifiers
> is not part of the parser and will be added in a separate patch.
>
> For now the rcar_jpu, s5p-jpeg and mtk-jpeg conversions are dropped.
> Instead, a few CODA fixes were added that should avoid alignment issues
> with odd-sized JPEG images and that stop tricking GStreamer into
> negotiating NV12 and then switching to YUV420 instead in S_FMT.
>
> regards
> Philipp
>
> Philipp Zabel (6):
> media: coda: round up decoded buffer size for all codecs
> media: add v4l2 JPEG helpers
> media: coda: jpeg: add CODA960 JPEG decoder support
> media: coda: split marking last meta into helper function
> media: coda: mark last capture buffer
> media: coda: lock capture queue wakeup against decoder stop command
>
> drivers/media/platform/Kconfig | 1 +
> drivers/media/platform/coda/coda-common.c | 188 ++++++-
> drivers/media/platform/coda/coda-jpeg.c | 572 ++++++++++++++++++++
> drivers/media/platform/coda/coda.h | 10 +-
> drivers/media/v4l2-core/Kconfig | 4 +
> drivers/media/v4l2-core/Makefile | 2 +
> drivers/media/v4l2-core/v4l2-jpeg.c | 632 ++++++++++++++++++++++
> include/media/v4l2-jpeg.h | 135 +++++
> 8 files changed, 1519 insertions(+), 25 deletions(-)
> create mode 100644 drivers/media/v4l2-core/v4l2-jpeg.c
> create mode 100644 include/media/v4l2-jpeg.h
>
> --
> 2.20.1
next prev parent reply other threads:[~2020-03-22 21:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-18 18:35 [PATCH v2 0/6] v4l2 JPEG helpers and CODA960 JPEG decoder Philipp Zabel
2020-03-18 18:35 ` [PATCH v2 1/6] media: coda: round up decoded buffer size for all codecs Philipp Zabel
2020-03-18 18:35 ` [PATCH v2 2/6] media: add v4l2 JPEG helpers Philipp Zabel
2020-03-18 18:35 ` [PATCH v2 3/6] media: coda: jpeg: add CODA960 JPEG decoder support Philipp Zabel
2020-03-18 18:35 ` [PATCH v2 4/6] media: coda: split marking last meta into helper function Philipp Zabel
2020-03-18 18:35 ` [PATCH v2 5/6] media: coda: mark last capture buffer Philipp Zabel
2020-03-18 18:35 ` [PATCH v2 6/6] media: coda: lock capture queue wakeup against decoder stop command Philipp Zabel
2020-03-19 15:37 ` [PATCH v2 0/6] v4l2 JPEG helpers and CODA960 JPEG decoder Tim Harvey
2020-03-22 21:41 ` Adrian Ratiu [this message]
2020-03-22 22:52 ` Ezequiel Garcia
2020-03-23 6:56 ` Adrian Ratiu
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=87eetkgj99.fsf@collabora.com \
--to=adrian.ratiu@collabora.com \
--cc=ezequiel@collabora.com \
--cc=kernel@pengutronix.de \
--cc=linux-media@vger.kernel.org \
--cc=mirela.rabulea@nxp.com \
--cc=p.zabel@pengutronix.de \
--cc=tharvey@gateworks.com \
/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).