From 0c77371ad302aa51ca664fbb03f8472fdccf348a Mon Sep 17 00:00:00 2001 From: Mr Dave Date: Mon, 14 Sep 2015 20:43:39 -0600 Subject: [PATCH] Patch for bad image handling --- CHANGELOG | 1 + netcam_jpeg.c | 15 +++------------ 2 files changed, 4 insertions(+), 12 deletions(-) diff --git a/CHANGELOG b/CHANGELOG index 2194291e..948aa881 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -1,4 +1,5 @@ Summary of Changes + * Add patch from JonGuess(issue 151452) for treatment of partial netcam images. * Consolidate the Sqlite3 options into the code standard. * Draft revised motion_guide.html with new options. * Revise manual to have current options. diff --git a/netcam_jpeg.c b/netcam_jpeg.c index f5c0614a..1b5c65b3 100644 --- a/netcam_jpeg.c +++ b/netcam_jpeg.c @@ -67,24 +67,15 @@ static boolean netcam_fill_input_buffer(j_decompress_ptr cinfo) * path when a new image is to be processed. It is assumed that * this routine will only be called once for the entire image. * If an unexpected call (with start_of_file FALSE) occurs, the - * routine will insert a "fake" "end of image" marker and return - * to the library to process whatever data remains from the original - * image (the one with errors). - * - * I'm not yet clear on what the result (from the application's - * point of view) will be from this logic. If the application - * expects that a completely new image will be started, this will - * give trouble. + * routine calls ERREXIT(). */ if (src->start_of_file) { nbytes = src->length; src->buffer = (JOCTET *) src->data; } else { - /* Insert a fake EOI marker - as per jpeglib recommendation */ - MOTION_LOG(INF, TYPE_NETCAM, NO_ERRNO, "%s: **fake EOI inserted**"); - src->buffer[0] = (JOCTET) 0xFF; - src->buffer[1] = (JOCTET) JPEG_EOI; /* 0xD9 */ nbytes = 2; + MOTION_LOG(DBG, TYPE_NETCAM, NO_ERRNO, "%s: Not enough data from netcam."); + ERREXIT(cinfo, JERR_INPUT_EOF); } src->pub.next_input_byte = src->buffer;