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 745599 - rtsp: tcp transport fails
rtsp: tcp transport fails
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 745672 (view as bug list)
Depends on:
Blocks: 745704
Reported: 2015-03-04 13:16 UTC by Matthew Waters (ystreet00)
Modified: 2015-03-05 21:29 UTC
See Also:
GNOME target: ---
GNOME version: ---

GST_DEBUG=3,rt*p*:7 log (61.98 KB, text/plain)
2015-03-04 14:01 UTC, Matthew Waters (ystreet00)
rtspsrc: Fix handling of interleaved (TCP) streams (1.81 KB, patch)
2015-03-05 08:22 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Matthew Waters (ystreet00) 2015-03-04 13:16:00 UTC
With git master of everything and the following test case fails.

gst-rtsp-server/examples/test-launch "( videotestsrc pattern=18 ! video/x-raw,width=320,height=180 ! timeoverlay ! vp8enc ! rtpvp8pay name=pay0 pt=96 )"

gst-launch-1.0 rtspsrc location=rtsp:// 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
Comment 1 Sebastian Dröge (slomo) 2015-03-04 13:26:33 UTC
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.
Comment 2 Matthew Waters (ystreet00) 2015-03-04 13:50:49 UTC
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.
Comment 3 Sebastian Dröge (slomo) 2015-03-04 13:52:17 UTC
And is there really a gap, i.e. received an RTP packet with a sequence number discontinuity?
Comment 4 Matthew Waters (ystreet00) 2015-03-04 14:01:08 UTC
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.
Comment 5 Sebastian Dröge (slomo) 2015-03-04 14:10:05 UTC
That would be the actual bug here then
Comment 6 Matthew Waters (ystreet00) 2015-03-04 14:21:25 UTC
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.
Comment 7 Sebastian Dröge (slomo) 2015-03-05 08:11:20 UTC
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.
Comment 8 Sebastian Dröge (slomo) 2015-03-05 08:22:50 UTC
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 9 Sebastian Dröge (slomo) 2015-03-05 11:16:09 UTC
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
Comment 10 Sebastian Dröge (slomo) 2015-03-05 11:16:46 UTC
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.
Comment 11 Sebastian Dröge (slomo) 2015-03-05 11:37:04 UTC
*** Bug 745672 has been marked as a duplicate of this bug. ***
Comment 12 Sebastian Dröge (slomo) 2015-03-05 12:22:46 UTC
Lost packet seems to be on the server side, it happens with UDP too.