GNOME Bugzilla – Bug 579808
[jpegdec] Doesn't support additional 0xff before end marker
Last modified: 2009-05-06 11:25:18 UTC
Some Sony IP camera's insert extra 0xff bytes before the end marker (I would guess for alignment, except that it aligns to an odd byte...). jpegdec, however, only skips over 0xff bytes if they don't appear in front of the end marker. Example JPEG and patch follow.
Created attachment 133094 [details] JPEG file that is not decoded by jpegdec This JPEG file contains 0xff 0xff 0xd9 at the end. jpegdec fails to identify this as an end marker. Test with gst-launch -v --gst-debug=jpegdec:5 filesrc location=sony.jpeg blocksize=32000 ! jpegdec ! fakesink (blocksize is set to avoid getting lots of debug output before the full frame is read). Test output: 0:00:00.077945265 7231 0x606080 DEBUG jpegdec gstjpegdec.c:278:gst_jpeg_dec_init: initializing Setting pipeline to PAUSED ... Pipeline is PREROLLING ... 0:00:00.078798258 7231 0x7404d0 DEBUG jpegdec gstjpegdec.c:1078:gst_jpeg_dec_sink_event:<jpegdec0> event : newsegment 0:00:00.078835414 7231 0x7404d0 DEBUG jpegdec gstjpegdec.c:1097:gst_jpeg_dec_sink_event:<jpegdec0> Got NEWSEGMENT [0:00:00.000000000 - 0:00:00.000030917 / 0:00:00.000000000] 0:00:00.078873688 7231 0x7404d0 DEBUG jpegdec gstjpegdec.c:431:gst_jpeg_dec_parse_image_data: Parsing jpeg image data (30917 bytes) 0:00:00.078888705 7231 0x7404d0 DEBUG jpegdec gstjpegdec.c:487:gst_jpeg_dec_parse_image_data: 0x00000002: tag e2, frame_len=115 0:00:00.078902184 7231 0x7404d0 DEBUG jpegdec gstjpegdec.c:487:gst_jpeg_dec_parse_image_data: 0x00000077: tag db, frame_len=132 0:00:00.078914477 7231 0x7404d0 DEBUG jpegdec gstjpegdec.c:487:gst_jpeg_dec_parse_image_data: 0x000000fd: tag c0, frame_len=17 0:00:00.078926559 7231 0x7404d0 DEBUG jpegdec gstjpegdec.c:487:gst_jpeg_dec_parse_image_data: 0x00000110: tag c4, frame_len=418 0:00:00.078938572 7231 0x7404d0 DEBUG jpegdec gstjpegdec.c:487:gst_jpeg_dec_parse_image_data: 0x000002b4: tag da, frame_len=12 0:00:00.078950166 7231 0x7404d0 DEBUG jpegdec gstjpegdec.c:500:gst_jpeg_dec_parse_image_data: 0x000002b4: finding entropy segment length 0:00:00.079004574 7231 0x7404d0 DEBUG jpegdec gstjpegdec.c:510:gst_jpeg_dec_parse_image_data: entropy segment length=30208 => frame_len=30220 0:00:00.079017984 7231 0x7404d0 LOG jpegdec gstjpegdec.c:1026:gst_jpeg_dec_chain:<jpegdec0> we need more data 0:00:00.079038797 7231 0x7404d0 DEBUG jpegdec gstjpegdec.c:1078:gst_jpeg_dec_sink_event:<jpegdec0> event : eos /pipeline0/fakesink0: last-message = "event ******* E (type: 102, GstEventNewsegment, update=(boolean)false, rate=(double)1, applied_rate=(double)1, format=(GstFormat)GST_FORMAT_BYTES, start=(gint64)0, stop=(gint64)30917, position=(gint64)0;) 0x738980" Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock /pipeline0/fakesink0: last-message = "event ******* E (type: 86, ) 0x738d40" Got EOS from element "pipeline0". Execution ended after 158684 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ...
Created attachment 133103 [details] [review] jpegdec: support additional 0xff before end marker. JPEG markers may be preceded by additional 0xff. jpegdec should skip over these, even before the end marker. Note that this patch makes the code look slightly awkward. This is to have minimal invasiveness.
Created attachment 133104 [details] [review] jpegdec: refactored gst_jpeg_dec_parse_image_data(). While I was at it, I refactored the function some more. I believe this also fixes a potential issue when resyncing: this didn't happen correctly for markers d0 - d7. This patch should be applied on top of attachment #133103 [details]
commit 99efbfcf4d52cf8a44d521e6942ada4fc4bbf2ea Author: Arnout Vandecappelle <arnout@mind.be> Date: Wed May 6 13:22:51 2009 +0200 jpegdec: refactored gst_jpeg_dec_parse_image_data Fixes #579808 commit 788986e26987634c924263d280cd8fa4f8eb4990 Author: Arnout Vandecappelle <arnout@mind.be> Date: Wed May 6 13:11:53 2009 +0200 jpegdec: support additional 0xff before end marker. JPEG markers may be preceded by additional 0xff. jpegdec should skip over these, even before the end marker. See #579808