Hi Hans, On Monday, 1 October 2018 19:28:58 EEST Hans Verkuil wrote: > On 10/01/2018 06:12 PM, Ezequiel Garcia wrote: > > On Mon, 2018-10-01 at 08:42 -0400, Nicolas Dufresne wrote: > >> Le lundi 01 octobre 2018 à 10:43 +0200, Hans Verkuil a écrit : > >>> It turns out that we have both JPEG and Motion-JPEG pixel formats > >>> defined. > >>> > >>> Furthermore, some drivers support one, some the other and some both. > >>> > >>> These pixelformats both mean the same. > >>> > >>> I propose that we settle on JPEG (since it seems to be used most often) > >>> and add JPEG support to those drivers that currently only use MJPEG. > >> > >> Thanks for looking into this. As per GStreamer code, I see 3 alias for > >> JPEG. V4L2_PIX_FMT_MJPEG/JPEG/PJPG. I don't know the context, this code > >> was written before I knew GStreamer existed. It's possible there is a > >> subtle difference, I have never looked at it, but clearly all our JPEG > >> decoder handle these as being the same. > >> > >> https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/sys/v4l2/gst > >> v4l2object.c#n956 > > > > To add more data points on the gstreamer side, there's really no > > difference between gstreamer's types image/jpeg and video/x-jpeg. > > > > Notably, jpegdec element just stuffs a huffman table if one is missing, > > for any jpeg: > > > > https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/ext/jpeg/gstj > > pegdec.c#n584 > > lib/libv4lconvert/libv4lconvert.c also treats JPEG and MJPEG the same. > > It looks like JPEG and MJPEG are randomly used and I don't think you can > assume that one will have a huffman table and not the other. That at least should be fixed. If we decide that whether the frames will contain a Huffman table or not is useful information for userspace, then we should convey it, either through the current mechanism (JPEG vs. MJPEG) or through a different mechanism. Otherwise, we can merge JPEG and MJPEG (as long as it doesn't break userspace). -- Regards, Laurent Pinchart
