GNOME Bugzilla – Bug 609055
[qtmux - mp4mux] crash when setting
Last modified: 2010-02-22 21:46:45 UTC
I receive from a rtspsrc demux with rtph264depay, link to a tee, linked to a mp4mux. rtsprc and rtph264depay are inside a bin, tee is just alone and mp4mux is in another bin. If a link rtspsrc/rtph264depay bin with tee with link_filtered then mp4mux crashes, but if i use normal link it just gives me an error (this error is normal). I am using python bindings, also all versions are from the Ubuntu 9.10 official repository. Here is the backtrace:
+ Trace 220422
Thread 1 (Thread 17397)
Can you post the code you use to create the pipeline and link_filtered so I can reproduce over here?
This goes in the constructor of a custom Bin self.muxer = gst.element_factory_make('ffmux_mp4') # mp4mux ffmux_mp4 self.file_sink = gst.element_factory_make('filesink') self.add(self.muxer) self.add(self.file_sink) self.muxer.link(self.file_sink) self.video_pad_sink = self.muxer.get_request_pad('video_%d') ghost_pad = gst.GhostPad('sink', self.video_pad_sink) ghost_pad.set_active(True) self.add_pad(ghost_pad) For linking i do this, self.source is a bin containing rtspsrc and rtph264depay. This is called when rtspsrc notifies that it creates a new pad. self.source.link(self.tee, 'video/x-h264, width=640, height=480, framerate=25/1')
By 'code' I mean a working example that makes it fail, sorry if I wasn't clear enough. A link to a rtsp stream you're using to test is also helpful. If you can't provide those, run your application with: GST_DEBUG=qtmux:5 yourapp > gst.log 2>&1 and attach the log (compressed) here.
0:00:00.129869867 [333m12446[00m 0x86adbd8 [37mLOG [00m [00m qtmux gstqtmux.c:2116:gst_qt_mux_register:[00m Registering muxers 0:00:00.130313937 [333m12446[00m 0x86adbd8 [37mLOG [00m [00m qtmux gstqtmux.c:2145:gst_qt_mux_register:[00m Finished registering muxers 0:00:00.131467065 [333m12446[00m 0x86adbd8 [36mDEBUG [00m [00m qtmux gstqtmux.c:1924:gst_qt_mux_request_new_pad:<mp4mux0>[00m Requested pad: (NULL) 0:00:01.165892632 [333m12446[00m 0x8869b40 [36mDEBUG [00m [00m qtmux gstqtmux.c:1686:gst_qt_mux_video_sink_set_caps:<mp4mux0>[00m mp4mux0:pad0, caps=video/x-h264, width=(int)640, height=(int)480, framerate=(fraction)25/1 0:00:01.165961094 [333m12446[00m 0x8869b40 [36mDEBUG [00m [00m qtmux gstqtmux.c:1720:gst_qt_mux_video_sink_set_caps:<mp4mux0>[00m Rate of video track selected: 2500 0:00:01.165978259 [333m12446[00m 0x8869b40 [33;01mWARN [00m [00m qtmux gstqtmux.c:1786:gst_qt_mux_video_sink_set_caps:<mp4mux0>[00m no codec_data in h264 caps
I still can't reproduce or figure out why it is crashing. Can you attach an sample app that makes it crash?
I have tried to make a sample application but i cannot make it crash. Ask me which information do you want to know and i will answer you. For more responsiveness also i am usually available on IRC.
Created attachment 153531 [details] Source code that crash The program connects to an IP camera and receives h264.
RTSP url to test source code: rtsp://video2.multicasttech.com/AFTVSciFiH2641000.sdp Is necessary to put this url if file camera_source_bin.py line 'source = gst.element_make_from_uri(gst.URI_SRC, location)'
This URI does not seem to work, do you have another one?
hm, it plays on quicktime, I must be doing something wrong with gstreamer. I'll keep trying :)
Just made it crash, assigning it to me.
This doesn't look entirely right (not the state change to READY + reset and MOOV free in the middle): gstqtmux.c:2507:gst_qt_mux_request_new_pad:<mp4mux0> Requested pad: video_00 now 1: 563600292935447 base_time 1: 0 running time 1: 563600292935447 link queue -> file_sink True gstqtmux.c:2652:gst_qt_mux_change_state: NULL -> READY gstqtmux.c:2652:gst_qt_mux_change_state: READY -> PAUSED <enum GST_STATE_CHANGE_ASYNC of type GstStateChangeReturn> now 2: 563600293534199 base_time 2: 598752 gstqtmux.c:2652:gst_qt_mux_change_state: PAUSED -> READY gstqtmux.c:294:gst_qt_mux_reset: Freeing MOOV gstqtmux.c:2652:gst_qt_mux_change_state: READY -> PAUSED NUEVO PAD SOURCE VIDEO gstqtmux.c:2186:gst_qt_mux_video_sink_set_caps:<mp4mux0> mp4mux0:video_00, caps=video/x-h264, width=(int)640, height=(int)480, framerate=(fraction)25/1 gstqtmux.c:2220:gst_qt_mux_video_sink_set_caps:<mp4mux0> Rate of video track selected: 2500 gstqtmux.c:2291:gst_qt_mux_video_sink_set_caps:<mp4mux0> no codec_data in h264 caps *BOOM*
I've already identified the problem, it is that we shouldn't iterate on collectpads data variable. I'm waiting for a resolution if we should add new API from bug #610366 to fix this with the new API or store them on the element.
Created attachment 154396 [details] [review] qtmux: Use internal sink pads list This patch fixes it for me, could you test it too, please?
With that patch now qtmux doesn't segment fault, i just get this output (i don't know if this output is correct or not): now 1: 24614064429865 base_time 1: 0 running time 1: 24614064429865 link queue -> file_sink True <enum GST_STATE_CHANGE_ASYNC of type GstStateChangeReturn> now 2: 24614065001213 base_time 2: 571348 NUEVO PAD SOURCE AUDIO NUEVO PAD SOURCE VIDEO Error: Could not multiplex stream. gstqtmux.c(1726): gst_qt_mux_add_buffer (): /GstPipeline:pipeline0/GstBin:bin1/GstMP4Mux:mp4mux0: Received buffer without timestamp/duration. Error: GStreamer encountered a general stream error. gstrtspsrc.c(3447): gst_rtspsrc_loop (): /GstPipeline:pipeline0/GstBin:bin0/GstRTSPSrc:rtspsrc0: streaming task paused, reason error (-5) saliendo /GstPipeline:pipeline0/GstQueue:queue_camera (__main__.GstQueue)
> Error: Could not multiplex stream. gstqtmux.c(1726): gst_qt_mux_add_buffer (): > /GstPipeline:pipeline0/GstBin:bin1/GstMP4Mux:mp4mux0: > Received buffer without timestamp/duration. > Error: GStreamer encountered a general stream error. gstrtspsrc.c(3447): > gst_rtspsrc_loop (): /GstPipeline:pipeline0/GstBin:bin0/GstRTSPSrc:rtspsrc0: > streaming task paused, reason error (-5) qtmux needs proper durations on input buffers. The easiest way to achieve that is to do something like this: ... ! videorate ! video/x-raw-yuv,framerate=25/1 ! x264enc ! .... I'm guessing there will be other problems with your code as well, that state change that caused the crash does not really look 'normal' to me.
(had already written while Tim posted) That's another problem, some element along the pipeline should be settings timestamps/durations on the buffers. Qtmux/mp4mux needs them to work. Marking it as a blocker as this is a crasher :)
I don't need that the code that i posted work as i have coded it in another way. If you want to study further what is happening it is ok, but for my part this bug can be closed because it doesn't crash now.
Comment on attachment 154396 [details] [review] qtmux: Use internal sink pads list I guess this is ok to push
Fixed. Module: gst-plugins-bad Branch: master Commit: ca136fe76bc3450677cbe26bfbe1afe7485de879 URL: http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=ca136fe76bc3450677cbe26bfbe1afe7485de879 Author: Thiago Santos <thiago.sousa.santos@collabora.co.uk> Date: Mon Feb 22 10:48:11 2010 -0300 qtmux: Use internal sink pads list Due to GstCollectPads sink pads list being not reliably iteratable (when not inside the collected function) this patch adds a sink pads list to qtmux to be used when iterating sink pads on reset function. Fixes #609055
Thanks. Now if someone could think of a more accurate (and complete) bug summary... :-)