GNOME Bugzilla – Bug 662147
Every pipeline breaks with internal error
Last modified: 2011-10-19 11:44:35 UTC
I'm not sure where this is breaking. Here's my pipeline: # gst-launch -ve filesrc location=/tmp/raw.yuv do-timestamp=TRUE ! 'video/x-raw-yuv,format=(fourcc)UYVY,width=720,height=480,framerate=30/1' ! TIVidenc1 codecName=h264enc engineName=codecServer byteStream=FALSE ! video/x-h264 ! mp4mux ! filesink location=dsptest.mp4 This breaks with these messages: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw-yuv, format=(fourcc)UYVY, width=(int)720, height=(int)480, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstTIVidenc1:tividenc10.GstPad:sink: caps = video/x-raw-yuv, format=(fourcc)UYVY, width=(int)720, height=(int)480, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstTIVidenc1:tividenc10.GstPad:src: caps = video/x-h264, framerate=(fraction)30000/1001, width=(int)720, height=(int)480, codec_data(buffer)0142801effe100126742801ee901687a42000007d00001d4c00801000468ce3c80 /GstPipeline:pipeline0/GstCapsFilter:capsfilter1.GstPad:src: caps = video/x-h264, framerate=(fraction)30000/1001, width=(int)720, height=(int)480, codec_data(buffer)0142801effe100126742801ee901687a42000007d00001d4c00801000468ce3c80 /GstPipeline:pipeline0/GstCapsFilter:capsfilter1.GstPad:sink: caps = video/x-h264, framerate=(fraction)30000/1001, width(int)720, height=(int)480, codec_data(buffer)0142801effe100126742801ee901687a42000007d00001d4c00801000468ce3c80 (gst-launch-0.10:836): GStreamer-CRITICAL **: gst_mini_object_unref: assertion `GST_IS_MINI_OBJECT (mini_object)' failed /GstPipeline:pipeline0/GstMP4Mux:mp4mux0.GstPad:src: caps = video/quicktime, variant=(string)iso /GstPipeline:pipeline0/GstFileSink:filesink0.GstPad:sink: caps = video/quicktime, variant=(string)iso Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline:pipeline0/GstMP4Mux:mp4mux0: Internal GStreamer error: negotiation problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer. Additional debug info: gstqtmux.c(2404): gst_qt_mux_add_buffer (): /GstPipeline:pipeline0/GstMP4Mux:mp4mux0: format wasn't negotiated before buffer flow on pad video_00 Execution ended after 3356933 ns. Setting pipeline to PAUSED ... /GstPipeline:pipeline0/GstMP4Mux:mp4mux0.GstPad:src: caps = video/quicktime, variant=(string)iso, streamheader=(buffer)<0 00001a96d6f6f760000006c6d76686400000000cac274f9cac274f9000003e80000000000010000010000000000000000000000000100000000000000 0000000000000000010000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000200000135747 2616b0000005c746b686400000007cac274f9cac274f90000000100000000000000000000000000000000000000000000000000010000000000000000 00000000000000010000000000000000000000000000400000000000000000000000000000d16d646961000000206d64686400000000cac274f9cac27 4f90000000000000000000000000000002168646c7200000000000000000000000000000000000000000000000000000000886d696e66000000246469 6e660000001c6472656600000000000000010000000c75726c20000000010000005c7374626c000000107374736400000000000000000000001073747 473000000000000000000000010737473630000000000000000000000147374737a000000000000000000000000000000107374636f00000000000000 00 > Setting pipeline to READY ... /GstPipeline:pipeline0/GstFileSink:filesink0.GstPad:sink: caps = video/quicktime, variant=(string)iso, streamheader=(buff er)< 000001a96d6f6f760000006c6d76686400000000cac274f9cac274f9000003e80000000000010000010000000000000000000000000100000000 0000000000000000000000010000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000200000 1357472616b0000005c746b686400000007cac274f9cac274f90000000100000000000000000000000000000000000000000000000000010000000000 0000000000000000000010000000000000000000000000000400000000000000000000000000000d16d646961000000206d64686400000000cac274f9 cac274f90000000000000000000000000000002168646c7200000000000000000000000000000000000000000000000000000000886d696e660000002 464696e660000001c6472656600000000000000010000000c75726c20000000010000005c7374626c0000001073747364000000000000000000000017 3747473000000000000000000000010737473630000000000000000000000147374737a000000000000000000000000000000107374636f0000000000 000000 > Note: this same pipeline used to work (obviously as it is quoted by the TI webpage http://processors.wiki.ti.com/index.php/Example_GStreamer_Pipelines#Encode_Video_Files_7) I have also has success with it in previous versions of gstreamer.
Thanks for taking the time to report this bug. Without a stack trace from the crash it's very hard to determine what caused it. Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
(In reply to comment #1) > Thanks for taking the time to report this bug. > Without a stack trace from the crash it's very hard to determine what caused > it. > Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces > for more information on how to do so. Thanks in advance! How can I get a stack trace on a program that's not crashing? It's just generating an internal error. A full gst-debug='*:7' is at http://www.mlbassoc.com/misc/gst-debug_2011-10-19
Uhm, there is no crash here as far as I can tell. Gary: it's probably because the encoder doesn't add "stream-format" and "alignment" fields to the h264 caps. It should be stream-format=(string)avc,alignment=(string)au. You can probably add those to the capsfilter, and have them added that way.
(In reply to comment #3) > Uhm, there is no crash here as far as I can tell. > > Gary: it's probably because the encoder doesn't add "stream-format" and > "alignment" fields to the h264 caps. It should be > stream-format=(string)avc,alignment=(string)au. You can probably add those to > the capsfilter, and have them added that way. Cool, that works! Thanks
Ok, great. Will close this bug then. (Admittedly it's a behavioural change on the muxer side, but I think it was changed before it was moved into -good. But even if not, it's probably better to error out and let the developer fix it than silently mux broken files in some cases.)
Sorry, I should have explained: the following is a bug that will get you a stack trace if run with G_DEBUG=fatal_criticals. I've not actually read the page about getting stack traces, so it might not be mentioned :) (gst-launch-0.10:836): GStreamer-CRITICAL **: gst_mini_object_unref: assertion `GST_IS_MINI_OBJECT (mini_object)' failed