[Bug 770935] RTP/RTSP/TCP transport RTSP TIMEOUT should start at once when tcpi_ca_state is TCP_CA_Loss
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Wed Sep 7 11:33:41 UTC 2016
https://bugzilla.gnome.org/show_bug.cgi?id=770935
--- Comment #4 from Dag Gullberg <opaque.se at gmail.com> ---
Created attachment 334978
--> https://bugzilla.gnome.org/attachment.cgi?id=334978&action=edit
Updated version with idefs and better handling
I used G_OS_UNIX ifdefs and put the use of it in a place where this feature
will only be used if the send to socket was OK, and then terminates as if OK,
but return generic error, if tcpi_ca_state == CA_STAT_Loss.
Tested and proved to work the same for the disconnect/failover case i am
working with.
On the reasoning if we want to check that state flag, well, the RTSP timeout is
by default 60s. The TCP timeout is set to 30-35 seconds, the retransmit
timeout is small in the first rounds. If you over the span of 60s (65s as it
turns out) does not see another state than Loss, well, then I think it is
reasonable to trigger that timeout.
The ambition is only to handle the RTSP timeout start more precise, not to
otherwise change the handling of sending data.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list