GNOME Bugzilla – Bug 777411
mpeg4videoparse ! avimux fails is_subset() accept-caps check from rtp
Last modified: 2018-05-07 14:33:50 UTC
Running the pipeline below will ends with "not-negotiated" error. gst-launch-1.0 -vvv udpsrc port=8888 ! application/x-rtp,clock-rate=90000 ! rtpmp4vdepay ! mpeg4videoparse ! video/mpeg ! avimux ! filesink location=/tmp/test.avi Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = "application/x-rtp\,\ clock-rate\=\(int\)90000\,\ media\=\(string\)video\,\ encoding-name\=\(string\)MP4V-ES" /GstPipeline:pipeline0/GstRtpMP4VDepay:rtpmp4vdepay0.GstPad:src: caps = "video/mpeg\,\ mpegversion\=\(int\)4\,\ systemstream\=\(boolean\)false" /GstPipeline:pipeline0/GstMpeg4VParse:mpeg4vparse0.GstPad:sink: caps = "video/mpeg\,\ mpegversion\=\(int\)4\,\ systemstream\=\(boolean\)false" /GstPipeline:pipeline0/GstRtpMP4VDepay:rtpmp4vdepay0.GstPad:sink: caps = "application/x-rtp\,\ clock-rate\=\(int\)90000\,\ media\=\(string\)video\,\ encoding-name\=\(string\)MP4V-ES" /GstPipeline:pipeline0/GstMpeg4VParse:mpeg4vparse0.GstPad:src: caps = "video/mpeg\,\ mpegversion\=\(int\)4\,\ systemstream\=\(boolean\)false\,\ parsed\=\(boolean\)true" /GstPipeline:pipeline0/GstMpeg4VParse:mpeg4vparse0.GstPad:src: caps = "video/mpeg\,\ mpegversion\=\(int\)4\,\ systemstream\=\(boolean\)false\,\ parsed\=\(boolean\)true\,\ profile\=\(string\)simple\,\ level\=\(string\)4a\,\ codec_data\=\(buffer\)000001b004000001b59113000001000000012000c8888007d28045a14103\,\ width\=\(int\)1280\,\ height\=\(int\)720\,\ pixel-aspect-ratio\=\(fraction\)1/1" ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal data flow error. Additional debug info: /home/poky/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/libs/gst/base/gstbasesrc.c(2933): gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: streaming task paused, reason not-negotiated (-4) Execution ended after 0:00:00.463042667 Nicolas from the developer forum tried a simpler pipeline using the master branch and it also failed. gst-launch-1.0 -v videotestsrc ! mpeg4videoparse ! avenc_mpeg4 ! avimux ! fakesink
(In reply to charles from comment #0) > Running the pipeline below will ends with "not-negotiated" error. > > gst-launch-1.0 -vvv udpsrc port=8888 ! application/x-rtp,clock-rate=90000 ! > rtpmp4vdepay ! mpeg4videoparse ! video/mpeg ! avimux ! filesink > location=/tmp/test.avi This won't work as-is as it's missing some important information in the rtp caps. > gst-launch-1.0 -v videotestsrc ! mpeg4videoparse ! avenc_mpeg4 ! avimux > ! fakesink mpeg4videoparse and avenc_mpeg4 are the wrong way around. However, with the server pipeline: gst-launch-1.0 -v videotestsrc ! avenc_mpeg4 ! mpeg4videoparse ! rtpmp4vpay ! udpsink host=127.0.0.1 port=8888 and client pipeline: GST_DEBUG=3,*CAPS*:5,*PAD*:5 gst-launch-1.0 -v udpsrc address=127.0.0.1 port=8888 caps='rtp caps from server pipeline' ! rtpmp4vdepay ! mpeg4videoparse ! avimux ! fakesink silent=false We see the issue that can be worked around by adding a video/mpeg,framerate=30/1 capsfilter after mpeg4videoparse.
Created attachment 343738 [details] Debug log for the avimux case
I am not sure that explains it. I have the exact client pipeline and it works if I replace the avimux with either mp4mux or matroskamux. Anyway, I tried your suggestion and I expanded the caps with info that I got from the server pipeline so the client pipeline now looks like the following. gst-launch-1.0 udpsrc address=127.0.0.1 port=8888 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, profile-level-id=(string)4, config=(string)000001b004000001b59113000001000000012000c8888007d28045a14103, payload=(int)96, ssrc=(uint)48003208, timestamp-offset=(uint)4244557471, seqnum-offset=(uint)28562" ! rtpmp4vdepay ! mpeg4videoparse ! video/mpeg,framerate=15/1 ! avimux ! filesink location=/tmp/test.avi However it still fails the same way. I have attached the debug log here with two cases. One with avimux and the other with mp4mux using the pipeline above. Hopefully there is some useful info there that may help. I do not know the gstreamer code enough to know what may be missing here.
Created attachment 343739 [details] debug log with mp4mux
I can't reproduce on 1.12+, are you sure this specific issue isn't fixed if you upgrade GStreamer ?
Closing for lack of response and Nicolas wasn't able to reproduce it a year ago. Charles, if you can reproduce the issue with current GStreamer, please reopen the bug.