On Fri, 2018-10-12 at 22:00 +0200, Paul Kocialkowski wrote: > Hi, > > Le mercredi 19 septembre 2018 à 13:28 +0900, Tomasz Figa a écrit : > > On Thu, Sep 13, 2018 at 9:15 PM Paul Kocialkowski <contact@xxxxxxxx> wrote: > > > Hi, > > > > > > On Wed, 2018-09-05 at 19:00 -0300, Ezequiel Garcia wrote: > > > > From: Shunqian Zheng <zhengsq@xxxxxxxxxxxxxx> > > > > > > > > Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace > > > > configure the JPEG quantization tables. > > > > > > > > Signed-off-by: Shunqian Zheng <zhengsq@xxxxxxxxxxxxxx> > > > > Signed-off-by: Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx> > > > > --- > > > > .../media/uapi/v4l/extended-controls.rst | 31 +++++++++++++++++++ > > > > .../media/videodev2.h.rst.exceptions | 1 + > > > > drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++++++ > > > > include/uapi/linux/v4l2-controls.h | 12 +++++++ > > > > include/uapi/linux/videodev2.h | 1 + > > > > 5 files changed, 55 insertions(+) > > > > > > > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst > > > > index 9f7312bf3365..1335d27d30f3 100644 > > > > --- a/Documentation/media/uapi/v4l/extended-controls.rst > > > > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > > > > @@ -3354,7 +3354,38 @@ JPEG Control IDs > > > > Specify which JPEG markers are included in compressed stream. This > > > > control is valid only for encoders. > > > > > > > > +.. _jpeg-quant-tables-control: > > > > > > I just had a look at how the Allwinner VPU handles JPEG decoding and it > > > seems to require the following information (in addition to > > > quantization): > > > > I assume the hardware doesn't have the ability to parse those from the > > stream and so they need to be parsed by user space and given to the > > driver? > > That's correct, we are also dealing with a stateless decoder here. It's > actually the same hardware engine that's used for MPEG2 decoding, only > configured differently. > > So we will need to introduce a pixfmt for compressed JPEG data without > headers, reuse JPEG controls that apply and perhaps introduce new ones > too if needed. > > I am also wondering about how MJPEG support should fit into this. As > far as I understood, it shouldn't be very different from JPEG so we > might want to have common controls for both. > We've recently discussed this and we were proposing to just drop MJPEG and stick to JPEG. The reason is that MJPEG is not clearly defined. Note that others treat MJPEG and JPEG as aliases. See "Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG". Also, I'll be adding support for spec-compliant JPEG frames in rockchip JPEG encoder. This will allow to use the driver with already available userspace. IOW, we don't absolutely need a new pixelformat for encoders. Decoders, on the other side, would be a different story, as parsing headers in the kernel can raise some safety concerns. Regards, Ezequiel
