GNOME Bugzilla – Bug 668874
rtpmp2tdepay: Negotiation problem
Last modified: 2012-05-21 18:44:08 UTC
I had a problem when trying to send muxed video(h264)+audio(mp3) using MPEG TS container through network via RTP+UDP. The sender was a custom board with LTIB Linux from Freescale. The receiver was a PC with Ubuntu 9.04 . The sender command: gst-launch -vvv mfw_v4lsrc capture-width=320 capture-height=240 ! mfw_vpuencoder codec-type=std_avc bitrate=600 ! mux. alsasrc ! queue ! audioconvert ! mfw_mp3encoder !mux. ffmux_mpegts name=mux ! rtpmp2tpay ! udpsink host=192.168.10.84 port=5555 The receiver command: gst-launch -vvv udpsrc port=5555 ! queue ! rtpmp2tdepay ! ffdemux_mpegts name=demux ! ffdec_h264 ! xvimagesink demux. ! queue ! mad ! alsasink The error message on receiver: Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline:pipeline0/GstRtpMP2TDepay:rtpmp2tdepay0: Internal GStreamer error: negotiation problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer. Additional debug info: gstbasertpdepayload.c(360): gst_base_rtp_depayload_chain (): /GstPipeline:pipeline0/GstRtpMP2TDepay:rtpmp2tdepay0: Not RTP format was negotiated Execution ended after 108278531 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... -------------------------------------- After that, I tried a PC-PC transmission on the same machine using localhost. The same error message was given. The 2nd sender command:gst-launch -vvv v4l2src ! x264enc ! mux. alsasrc ! queue ! audioconvert ! lamemp3enc ! mux. ffmux_mpegts name=mux ! rtpmp2tpay ! udpsink host=192.168.10.84 port=5555 The 2nd receiver command remains the same.
Adding a colorspace element between v4l2src and x264enc makes the second pipeline work. Does it also make the first one work ?
Oh wait, you did not have an issue with the sender, nevermind. Probably my v4l2src not having the same formats as yours and causing the need for a colorspace.
Right, I get the same error as well.
Created attachment 206438 [details] [review] rtpmp2tpay: do not try to flush a packet when no data is available
The sending pipeline shows ffmpeg being unhappy about the incoming stream. 0:00:13.101645771 21441 0x2074f20 ERROR ffmpeg :0:: h264 bitstream malformated, no startcode found, use -vbsf h264_mp4toannexb 0:00:13.123919620 21441 0x2257cf0 ERROR ffmpeg :0:: Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1009745 >= 1003188 Also a critical in rtpmp2tpay fixed by the patch above.
For the record, the receiving pipeline goes to PLAYING if I add "caps=application/x-rtp" to udpsrc (though it won't display anything, presumably due to the sending pipeline throwing errors for me).
That last problem appears due to ffmux_mpegts not properly handling the stream-format=avc input case. As such, note that tsmux is likely recommended these days (and no more ffdemux_mpegts around either afaics). And w.r.t. the original one, the (base) depayloader will want some caps, which is not set by some udpsrc, so that will indeed have to be provided for.
Hi, Mark. Do you have any suggestions of a correct pipeline string for gst-launch with wanted caps? Thanks for the help. (In reply to comment #7) > That last problem appears due to ffmux_mpegts not properly handling the > stream-format=avc input case. As such, note that tsmux is likely recommended > these days (and no more ffdemux_mpegts around either afaics). > > And w.r.t. the original one, the (base) depayloader will want some caps, which > is not set by some udpsrc, so that will indeed have to be provided for.
(In reply to comment #8) > Hi, Mark. Do you have any suggestions of a correct pipeline string for > gst-launch with wanted caps? As suggested in Comment #6, which I presume comes down to either adding a capsfilter (with specified caps) after udpsrc, or setting udpsrc caps property to those caps.