GNOME Bugzilla – Bug 706422
jpegenc is sending wrong buffer on specific input/resolution
Last modified: 2013-08-21 11:04:29 UTC
When using the following pipelines for sending/receiving an jpeg encoded videostream using videotestsrc and udpsink, the receiver cancels with the following error message: When starting above pipelines or this sample application you will encounter the following error on receiving end: ** (gst-launch-1.0:32310): CRITICAL **: gst_adapter_push: assertion `GST_IS_BUFFER (buf)' failed ** (gst-launch-1.0:32310): CRITICAL **: gst_jpeg_dec_fill_input_buffer: assertion `dec->current_frame_map.data != NULL' failed ** (gst-launch-1.0:32310): CRITICAL **: gst_jpeg_dec_fill_input_buffer: assertion `dec->current_frame_map.data != NULL' failed ERROR: From element /GstPipeline:pipeline0/GstJpegDec:jpegdec0: Failed to decode JPEG image Additional diagnostic information: gstjpegdec.c(1295): gst_jpeg_dec_handle_frame (): /GstPipeline:pipeline0/GstJpegDec:jpegdec0: number of components not supported: 3 (max 3) Use these pipelines for reproduction: RECEIVER: gst-launch-1.0 -v udpsrc port=9001 ! "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)JPEG, payload=(int)96" ! rtpjpegdepay ! jpegdec ! autovideosink SENDER: gst-launch-1.0 -v videotestsrc pattern=1 ! "video/x-raw, width=(int)640, height=(int)480, framerate=(fraction)30/1, format=(string)I420" ! jpegenc ! rtpjpegpay ! udpsink host=127.0.0.1 port=9001 The problem was encountered using GStreamer 1.0.8 and verified also with GStreamer 1.0.9. It will only occur with pattern=1 of videotestsrc and with 640x480 resolution. When using pattern=0 and resolution 320x240 I could not see the error. When using avenc_mjpeg instead of jpegenc the problem also seems to be fixed. Therefore I guess its a problem of jpegenc.
The core problem is in the depayloader base class not tagging DISCONT correctly. This caused the jpegdepayloader to keep a large amount of unrelated packets and feeding the decoder with bad input. The decoder should also be made a bit more reliable. commit 121235511a5a25dfa5318b4b02491d219ecdd87e Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Wed Aug 21 12:34:24 2013 +0200 rtpbasedepayload: mark DISCONT on buffer in all cases Always mark discont on the input buffer when we detect a seqnum discont and not only when we previously marked ourselves DISCONT. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=706422
The video decoder has a parse error but then the base class still calls the handle_frame method with a NULL input_buffer.