I know libjpeg will flag things like "Invalid SOS parameters for sequential JPEG" and I just patched jdhuff.c with some sed magic, so as not to produce the warning output to stderr on every frame.

Some cameras will also produce "Huffman table 0x00 was not defined" which I just patch the JPEG with https://github.com/sgjava/cvp/blob/master/cvpimage/MjpegPatch.py.

For "Invalid SOS parameters for sequential JPEG" I ended up using Pil https://github.com/sgjava/cvp/blob/master/cvpframe/MjpegPilFramePlugin.py

It looks like they fixed what you are seeing in Zoneminder http://www.netmedia.com/forums/viewtopic.php?f=6&t=524

On Fri, Mar 14, 2014 at 4:33 PM, tosiara <tosiara@gmail.com> wrote:

I have been investigating constant video signal lost on my ARM device. And finally found a possible cause. Here is log snip:

Corrupt JPEG data: premature end of data segment
Invalid JPEG file structure: two SOI markers
[1] [ERR] [ALL] motion_loop: Video device fatal error - Closing video device
[1] [NTC] [VID] vid_close: Closing video device /dev/video0

The message about "SOI markers" comes from function decode_jpeg_raw. This is the responsible code:

if (setjmp (jerr.setjmp_buffer)) {
        /* If we get here, the JPEG code has signaled an error. */
        jpeg_destroy_decompress (&dinfo);
        return -1;

Return value "-1" is V4L_FATAL_ERROR
If I change return value here from "-1" to "1" which means _not fatal error_ motion skips that single freaky frame and only generates single warning in log:

[1] [CRT] [VID] mjpegtoyuv420p: Corrupt image ... continue

I would like to get your comments: why single corrupted frame is treated as "FATAL ERROR" here? Why motion does not skip it as it skips other corrupted JPEGs?


Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
Motion-user mailing list

Steven P. Goldsmith