Re: [PATCH v2 0/6] v4l2 JPEG helpers and CODA960 JPEG decoder

[Adrian Ratiu <adrian.ratiu@collabora.com>]

[-- Attachment #1: Type: text/plain, Size: 3259 bytes --]

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 

Hi again,

When testing both v1 and v2 series, a subtle corner-case bug
leading to color degradation was observed on our IMX6DL board.

I'm documenting here so it will be a known issue if someone
else hits the rare corner-case.

In the attached archive there is an example img test420.jpeg.

It can be decoded & displayed correctly using the pipeline:

gst-launch-1.0 -v filesrc location=./test420.jpeg ! jpegparse ! 
v4l2jpegdec ! video/x-raw,format=NV12 ! imagefreeze ! kmssink

If any GIMP created jpeg like gimp_created_borks_colors.jpeg
is decoded in between, then all subsequent raw decoded images
until next reboot have their colors "degraded".

The archive has are two NV12 decoded images which exemplify
this degradation: before_gimp.raw and after_gimp.raw.

The raw files can be viewed with mplayer like this:
mplayer -demuxer rawvideo -rawvideo w=800:h=480:format=NV12 
./before_gimp.raw -loop 0

I am unsure what might be causing this degradation, we only
see it with GIMP-created images, but since our applications
are not creating jpegs with GIMP this is no problem for us.


[-- Attachment #2: test_jpegs.tar.xz --]
[-- Type: application/x-xz, Size: 76236 bytes --]

[-- Attachment #3: Type: text/plain, Size: 22 bytes --]


Thanks again,
Adrian