[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 08:31:52 UTC 2016


https://bugzilla.gnome.org/show_bug.cgi?id=770935

Sebastian Dröge (slomo) <slomo at coaxion.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #334899|none                        |needs-work
             status|                            |

--- Comment #2 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
Review of attachment 334899:
 --> (https://bugzilla.gnome.org/review?bug=770935&attachment=334899)

::: gst-libs/gst/rtsp/gstrtspconnection.c
@@ +3763,3 @@
+  getsockopt(g_socket_get_fd (sock),
+                      IPPROTO_TCP, TCP_INFO, &tcp_info, &optlen);
+  res = (tcp_info.tcpi_ca_state == TCP_CA_Loss);

This all should be conditional in #ifdefs :)

@@ +3820,3 @@
+       treat same as WOULD_BLOCK. Need this to avoid delay. */
+    if (check_tcp_ca_state_loss(watch->conn->write_socket))
+      res = GST_RTSP_EINTR;

The main difference between WOULD_BLOCK and this however is that WOULD_BLOCK
means that no data was written, here all data was written (to the OS internal
buffer). Is this handled correctly?

Also this can happen basically all the time without there being an actual
problem. TCP packets getting lost tell you nothing other than the link being
not ideal

-- 
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