Em Mon, 1 Oct 2018 18:19:21 +0100 Dave Stevenson <dave.stevenson@xxxxxxxxxxxxxxx> escreveu: > Hi All, > > On Mon, 1 Oct 2018 at 17:32, Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx> wrote: > > > > Hi Hans, > > > > Thanks for looking into. I remember MJPEG vs. JPEG being a source > > of confusion for me a few years ago, so clarification is greatly > > welcome :-) > > > > On Mon, 2018-10-01 at 15:03 +0300, Laurent Pinchart wrote: > > > Hi Hans, > > > > > > On Monday, 1 October 2018 14:54:29 EEST Hans Verkuil wrote: > > > > On 10/01/2018 01:48 PM, Laurent Pinchart wrote: > > > > > On Monday, 1 October 2018 11:43:04 EEST Hans Verkuil wrote: > > > > > > 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. > > > > > > > > > > Do they ? I thought MJPEG was JPEG using fixed Huffman tables that were > > > > > not included in the JPEG headers. > > > > > > > > I'm not aware of any difference. If there is one, then it is certainly not > > > > documented. > > > > > > What I can tell for sure is that many UVC devices don't include Huffman tables > > > in their JPEG headers. > > > > > > > Ezequiel, since you've been working with this recently, do you know anything > > > > about this? > > > > > > > > > > JPEG frames must include huffman and quantization tables, as per the standard. > > > > AFAIK, there's no MJPEG specification per-se and vendors specify its own > > way of conveying a Motion JPEG stream. > > There is the specfication for MJPEG in Quicktime containers, which > defines the MJPEG-A and MJPEG-B variants [1]. > MJPEG-B is not a concatenation of JPEG frames as the framing is > different, so can't really be combined into V4L2_PIX_FMT_JPEG. > Have people encountered devices that produce MJPEG-A or MJPEG-B via > V4L2? I haven't, but I have been forced to support both variants on > decode. Checking it is not an easy task. I *suspect* that those cameras are all MJPEG-A, as the libv4l decoder uses tinyjpeg library to handle both JPEG and MJPEG. Maybe Hans de Goede knows more about that, and may have actually tested it with different camera models. > > On that thought, whilst capture devices generally don't care, is there > a need to differentiate for M2M codec devices which can support > encoding the variants? Or likewise on M2M decoders that support only > JPEG, how do they tell userspace that they don't support MJPEG-A or > MJPEG-B? > > Dave > > [1] https://developer.apple.com/standards/qtff-2001.pdf > > > For instance, omiting the huffman table seems to be a vendor thing. Microsoft > > explicitly omits the huffman tables from each frame: > > > > https://www.fileformat.info/format/bmp/spec/b7c72ebab8064da48ae5ed0c053c67a4/view.htm > > > > Others could be following the same things. > > > > Like I mentioned before, Gstreamer always check for missing huffman table > > and adds one if missing. Gstreamer has other quirks for missing markers, > > e.g. deal with a missing EOI: > > > > https://github.com/GStreamer/gst-plugins-good/commit/10ff3c8e14e8fba9e0a5d696dce0bea27de644d7 > > > > I think Hans suggestion of settling on JPEG makes sense and it would > > be consistent with Gstreamer. Otherwise, we should specify exactly what we > > understand by MJPEG, but I don't think it's worth it. > > > > Thanks, > > Ezequiel Thanks, Mauro
