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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2020-03-22 at 23:41 +0200, Adrian Ratiu wrote:
> Hi Philipp,
> 
> Tested-by: Adrian Ratiu <adrian.ratiu@xxxxxxxxxxxxx>
> 
> 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.
> 
> 

I just had a chat with Adrian, and I suggested him to submit
his patches as regular patches, using the cover letter
to explain the dependency on this series.

We can then review the patches and discuss them as usual.

Also, I took a quick look at patch 2/2 and I was wondering
if maybe some more information about the use-case could
be helpful to understand the need for such change.

Thanks,
Ezequiel 

> 
> 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.
> 
> Thanks,
> Adrian
> 
> 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





[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux