After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 668874 - rtpmp2tdepay: Negotiation problem
rtpmp2tdepay: Negotiation problem
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.x
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-01-27 19:26 UTC by CINCINATO
Modified: 2012-05-21 18:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
rtpmp2tpay: do not try to flush a packet when no data is available (831 bytes, patch)
2012-01-30 14:55 UTC, Vincent Penquerc'h
committed Details | Review

Description CINCINATO 2012-01-27 19:26:07 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.
Comment 1 Vincent Penquerc'h 2012-01-30 14:40:49 UTC
Adding a colorspace element between v4l2src and x264enc makes the second pipeline work. Does it also make the first one work ?
Comment 2 Vincent Penquerc'h 2012-01-30 14:46:37 UTC
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.
Comment 3 Vincent Penquerc'h 2012-01-30 14:48:50 UTC
Right, I get the same error as well.
Comment 4 Vincent Penquerc'h 2012-01-30 14:55:09 UTC
Created attachment 206438 [details] [review]
rtpmp2tpay: do not try to flush a packet when no data is available
Comment 5 Vincent Penquerc'h 2012-01-30 14:57:21 UTC
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.
Comment 6 Vincent Penquerc'h 2012-01-30 15:14:35 UTC
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).
Comment 7 Mark Nauwelaerts 2012-05-18 13:36:26 UTC
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.
Comment 8 CINCINATO 2012-05-21 17:50:26 UTC
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.
Comment 9 Mark Nauwelaerts 2012-05-21 18:44:08 UTC
(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.