GNOME Bugzilla – Bug 758943
SEGV using rtpj2kdepay & openjpegdec
Last modified: 2015-12-18 10:10:59 UTC
The element rtpj2kpay raise a SIGSEGV signal with Gstreamer 1.6.1 (tested on Arch 4.2.5 and Debian testing). This bug is not present on Gstreamer 1.4.4 The pipeline used for test is: gst-launch-1.0 videotestsrc do-timestamp=true is-live=true ! video/x-raw,format=I420,framerate=10/1 !openjpegenc ! rtpj2kpay ! rtpj2kdepay ! openjpegdec ! fakesink 0:00:00.012015892 10449 0x23eb6d0 FIXME default gstutils.c:3766:gst_pad_create_stream_id_internal:<videotestsrc0:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id Passage du pipeline à la phase PLAYING… 0:00:00.012153310 10449 0x23eb6d0 FIXME videodecoder gstvideodecoder.c:1057:gst_video_decoder_drain_out:<openjpegdec0> Sub-class should implement drain() New clock: GstSystemClock Caught SIGSEGV Spinning. Please run 'gdb gst-launch-1.0 10449' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core. This might be an interaction between rtpj2kdepay and openjpegdec since theses pipelines doesn't crash videotestsrc do-timestamp=true is-live=true ! video/x-raw,format=I420,framerate=10/1 ! openjpegenc ! openjpegdec ! fakesink videotestsrc do-timestamp=true is-live=true ! video/x-raw,format=ARGB,framerate=10/1 ! openjpegenc ! rtpj2kpay ! rtpj2kdepay ! fakesink This problem might be linked to bug 756422
I got the same problem with gstreamer 1.6.2. The following pipeline causes a SEGFAULT while processing the first image in the element "openjpegdec" : gst-launch-1.0 videotestsrc ! video/x-raw, format=I420 ! openjpegenc ! rtpj2kpay ! rtpj2kdepay ! openjpegdec ! videoconvert ! autovideosink sync=false BUT the following one does not crash : gst-launch-1.0 videotestsrc ! video/x-raw, format=I420 ! openjpegenc ! openjpegdec ! videoconvert ! autovideosink sync=false The RTP deplayloader pushed buffer list but openjpegdec does not seem to be able to handle "parted" frame. For example, the "rtpj2kdepay" use "gst_rtp_base_depayload_push_list (depayload, buflist);" to push several small buffer. The concatenation of all small buffer of the buffer list corresponds to a video frame. The element "openjpegdec" has a callback for frame processing : "gst_openjpeg_dec_handle_frame()". But the buffer "frame->input_buffer" in this callback is not the whole frame, this is only "one" buffer of the buffer list pushed by the depayloader. If I changed the depayloader to push whole buffer, the first commande is working fine (see patch). Why does buffer list have been introduced in this depayloader ? Should we do something in the decoder to continue to use buffer list ?
Created attachment 317564 [details] [review] Test without buffer list in the RTP payloader
This fixes the crash at least, we shouldn't crash on decoding errors. But the RTP payloader or depayloader is somehow generating broken data here. commit 9b4611ccae8df20b70644be82efbeab026374a6b Author: Sebastian Dröge <sebastian@centricular.com> Date: Thu Dec 17 15:56:57 2015 +0100 openjpegdec: Don't crash when decoding returns NULL data for any component https://bugzilla.gnome.org/show_bug.cgi?id=758943
Your patch is correct, I was just starting to do the same :) Using a buffer list here doesn't make sense. We need one JPEG2000 frame per buffer.
commit c1b66a63acd3b9eaa638ca322b4b52a55085aa53 Author: Vincent Dehors <vincent.dehors@openwide.fr> Date: Thu Dec 17 16:03:04 2015 +0100 rtpj2kdepay: Push one JPEG2000 frame per buffer, not a buffer list with multiple buffers https://bugzilla.gnome.org/show_bug.cgi?id=758943
I'll backport both fixes to 1.6 later. Thanks!