Cannot open MJPEG image coming from Camera

[rggjan]

Opening the following MJPEG jpg file coming from a Logitech camera doesn't work in libjpeg-turbo.

While tjDecompressHeader3 works fine and returns the correct width and height of the image, tjDecompress2 returns with an error Could not decompress jpg: Corrupt JPEG data: 2 extraneous bytes before marker 0xd6.

The file opens fine in Firefox, for example:

[rggjan]

This could be related to the issue in this project: Motion-Project/motion#65:

The source of the problem is that the Logitech uses AVI1 format instead of JFIF and also occasionally fills the buffer with two SOI markers.

[dcommander]

That error message is just a warning from the underlying libjpeg API. The implementation of tjDecompress2() in libjpeg-turbo 1.5 will continue decoding the image regardless of the warning, although it still returns -1. However, with that version of the API, it's difficult to distinguish warnings from errors (you would have to specifically check the text of the error message and ignore it if it matches Could not decompress jpg: Corrupt JPEG data: 2 extraneous bytes before marker 0xd6.) The new version of the TurboJPEG API in libjpeg-turbo 1.6 evolving (dev branch) provides a method of determining whether the last error was a warning or a fatal error.

[rggjan]

Thanks @dcommander for the clarification, this helps!

[zwn]

Just wanted to say I have similar problem so I am looking forward to the 1.6 API. I get pictures from Arecont IP camera and the warning/error I get is "extraneous bytes before marker 0xd9". I believe it is related to this note about hardware encoders: https://tools.ietf.org/html/rfc2435#section-3.1.9:

The scan is terminated either implicitly (i.e., the point at which the image is fully parsed), or with an EOI marker. The scan may be padded to arbitrary with undefined bytes. (Some existing hardware codecs generate lines at the bottom of a video frame and removal of these lines require a Huffman-decoding pass over the data.)

The files are full of restart markers and the data after the last restart marker (before the eoi marker) is garbage. Having this reported as warning would be great. Not reporting it at all would be best. I was made aware of the problem because the default error action is to output this message to stderr while I could do nothing about it since I was going through python and opencv.

[dcommander]

The 1.6 API is already available in the dev branch and CI/pre-release builds built from that branch. Please give it a test. Documentation links are here: http://www.libjpeg-turbo.org/Documentation/Documentation

The primary changes that affect this issue are:

• a new flag (TJFLAG_STOPONWARNING) that makes warnings immediately fatal (the default behavior is to allow the compression/decompression/transform operation to complete if a warning is encountered, then to return -1.
• a new function (tjGetErrorCode()) that can be used to determine whether the last function returned -1 as the result of a warning (recoverable error) or a fatal, non-recoverable error.

Simply ignoring the -1 return code if tjGetErrorCode()==TJERR_WARNING has the effect of making warnings irrelevant, which is what you want.