GNOME Bugzilla – Bug 588144
rtspsrc: (network) timeout behaviour inconsistent between TCP and UDP
Last modified: 2018-11-03 14:39:59 UTC
rtspsrc's tcp_timeout property prevents rtspsrc from "hanging" if network timeout/interruption occurs during streaming (or interaction with RTSP server). However, no such (stringent) checks are performed when UDP happens to be selected (there may be some sender timeout detection in rtpbin/jitterbuffer, but the net overall effect/user experience is not quite the same). Although this may or may not be intentional and/or related to UDP issues (e.g. inherently less reliable than TCP), possible patch follows anyway.
Created attachment 138108 [details] [review] Check for UDP streaming timeout Note that tcp_timeout is (ab)used as the timeout value in question. As such, the semantics of the timeout properties are slightly shifted: - timeout is used as initial timeout (UDP -> TCP fallback) - tcp_timeout is used as streaming timeout (whether or not TCP)
RTP has some other timeout mechanisms in the session manager. Those are the timeouts that should be used according to the RTP spec. I believe we connect to the on-timeout and on-sender-timeout to catch (and stop) those kind of timeouts. Are you seeing a case where it never stops after a timeout?
No (i.e. UDP does eventually timeout), but I am seeing cases where a tcp-timeout set to e.g. 5 seconds leads to a timeout after 5 seconds if interleaved transport is selected, and only after +/- 30 seconds if UDP is selected. Since higher levels are conceivably not supposed to care about transport level issues, this is (somewhat) inconsistent behaviour, in the sense of the (UDP) "hanging" being different (by an "order of magnitude") and apparently not being affected/controllable by some property.
Reopening as the requested information has been provided.
Created attachment 171884 [details] sdp with bandwith information Actually, I am now seeing a case where it never stops after a timeout (as in bug #607579). This appears to be due to the session bandwidth configuration that was add in commit bc72d8250c0b6fb97212cf64bb41fc16af7fce38 in combination with a typical (WMServer) SDP (attached) that has RR=RS=0 bandwidth. That disables some RTCP stuff (which is likely not uncommon in RTSP cases), and in particular bypasses any (session sender) timeout checking. In contrast, checking for UDP streaming timeout would always apply, and be more consistent with the TCP transport case.
*** Bug 607579 has been marked as a duplicate of this bug. ***
What should be done with this bug?
Patches need to be rebased to apply against latest GIT. Wim, Mark? What should we do about this?
AFAICS situation is still as before. Could have a look at bringing up-to-date if there is consensus on how to proceed.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/15.