GNOME Bugzilla – Bug 745599
rtsp: tcp transport fails
Last modified: 2015-03-05 21:29:26 UTC
With git master of everything and the following test case fails. Server: gst-rtsp-server/examples/test-launch "( videotestsrc pattern=18 ! video/x-raw,width=320,height=180 ! timeoverlay ! vp8enc ! rtpvp8pay name=pay0 pt=96 )" Client: gst-launch-1.0 rtspsrc location=rtsp://127.0.0.1:8554/test protocols=0x4 ! rtpvp8depay ! vp8dec ! autovideosink (h264 fails as well) Bisect reveals that both of the following commits break tcp handling. 87c8c163a876f45024a817e17af6dfdc52e71257 rtpjitterbuffer: If we get a gap with a buffer without DTS, error out 52c040c89bd99bd11598a628934a2b48b1e9a64 rtspsrc: fix container handling Reverting them makes the pipeline run at the expense of a couple of warnings. (gst-launch-1.0:17575): GStreamer-WARNING **: gstpad.c:4793:store_sticky_event:<rtpsession0:sync_src> Sticky event misordering, got 'segment' before 'caps' (gst-launch-1.0:17575): GStreamer-WARNING **: gstpad.c:4793:store_sticky_event:<rtpssrcdemux0:rtcp_sink> Sticky event misordering, got 'segment' before 'caps' And the following on shutdown (gst-launch-1.0:17575): GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object->refcount > 0' failed
87c8c163a876f45024a817e17af6dfdc52e71257 would only be a problem if a packet gets lost over TCP... which should not really happen. You can check in the debug logs the sequence numbers at the receiver side.
With h264 (doesn't seem to happen with vp8) and 87c8c163a876f45024a817e17af6dfdc52e71257 not reverted you get 0:00:00.303828247 24503 0xe98320 WARN rtpjitterbuffer gstrtpjitterbuffer.c:2447:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> error: Received packet without DTS after a gap ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager/GstRtpJitterBuffer:rtpjitterbuffer0: Could not decode stream.
And is there really a gap, i.e. received an RTP packet with a sequence number discontinuity?
Created attachment 298533 [details] GST_DEBUG=3,rt*p*:7 log According to rtpsource, no. According to rtpjitterbuffer it wants a sequence number 4 ahead of the start.
That would be the actual bug here then
That's not the only bug, reverting 87c8c163a876f45024a817e17af6dfdc52e71257 but not 52c040c89bd99bd11598a628934a2b48b1e9a64 results in gst_rtsp_handle_data not finding the stream for the channel from the message its given and the single stream in src->streams is not initialised at all.
With both reverted it looks like a lot of packets get lost in the beginning. So reverting 87c8c163a876f45024a817e17af6dfdc52e71257 just works around the real problem. Looking at the container thing first now.
Created attachment 298606 [details] [review] rtspsrc: Fix handling of interleaved (TCP) streams We need to set up the transport in any case, not just if we have a container stream or a non-interleaved stream. Only if we have an interleaved stream and are retrying, we should not set up the stream again. Also fix the buffering condition for container streams. The comment says that we should not enable it for container streams, but the fix in 852c040c89bd99bd11598a628934a2b48b1e9a64 *only* enables it for container streams now.
Comment on attachment 298606 [details] [review] rtspsrc: Fix handling of interleaved (TCP) streams Pushed except for the buffering part as that one is not correct
Only remaining problem is that for some reason we miss the first packets or somehow receive broken first packets. libvpx does not like the first frames.
*** Bug 745672 has been marked as a duplicate of this bug. ***
Lost packet seems to be on the server side, it happens with UDP too.