[Bug 770934] RTSP TIMEOUT in RTP/RTSP/TCP transport not deterministic

[GStreamer (GNOME Bugzilla)]

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

--- Comment #10 from Dag Gullberg <opaque.se at gmail.com> ---
(In reply to Dag Gullberg from comment #9)
> Created attachment 336676 [details] [review]
> Update
> 
> Added comment in the patch

(In reply to Nicolas Dufresne (stormer) from comment #8)
> Review of attachment 336147 [details] [review]:
> 
> The commit message should be improved, it's neither clear or precise enough.
> 
> ::: gst-libs/gst/rtsp/gstrtspconnection.c
> @@ +3780,3 @@
>      guint size, guint * id)
>  {
> +  GstRTSPResult res = GST_RTSP_ERROR;
> 
> How is this related to timeout ?

I have now written a detailed commit message that clearly point out the benefit
of having the gst_rtsp_watch_write_data() return something else than
GST_RTSP_OK when the non-blocking write socket buffer is full. It has through a
double layer of CBs the benefit of not resetting the TIMEOUT timer when infact
there are problems sending.

I have checked the call chain and there are no other dependencies. Note that
this patch then allow for a even more elaborate improvent to be done, checkeing
when the TCP stack notice the NW problem. See
https://bugzilla.gnome.org/show_bug.cgi?id=770935 . Both these fixes together
makes the timeout behave like UDP/RTP using RTCP, where there is no unduly
delay in the starting of the timeout timer.

Ultimately this is beneficial to use cases concerned with NW going down, e.g.
fail-over local file save. As the other way to remedy this is to increase
buffer sizes to cover the delay, a hard to define quantity, it eats from a high
priced resource from the system, memory.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.