On Wed, 18 Mar 2020, Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> 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:
test_jpegs.tar.xz
Description: application/xz
Thanks again, Adrian
