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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #3 from Dag Gullberg <opaque.se at gmail.com> ---
Thanks for quick feedback.

gst_rtsp_stream_transport_send_rtp() in rtsp-stream-transport.c have a
construct like:

  if (priv->send_rtp)
    res =
        priv->send_rtp (buffer, priv->transport->interleaved.min,
        priv->user_data);

  if (res)
    gst_rtsp_stream_transport_keep_alive (trans);


The gst_rtsp_stream_transport_keep_alive function touches the timeout,
resetting it. This is what we would like to avoid if we don't actually have a
connection, momentary or not.

The send_rtp CB is set in rtsp-client handle_setup_request()

  if (ct->lower_transport == GST_RTSP_LOWER_TRANS_TCP) {
    /* our callbacks to send data on this TCP connection */
    gst_rtsp_stream_transport_set_callbacks (trans,
        (GstRTSPSendFunc) do_send_data,
        (GstRTSPSendFunc) do_send_data, client, NULL);

When streaming the following call chain is used:

rtsp-stream-transport::gst_rtsp_stream_transport_send_rtp()
    rtsp-client<cb>::do_send_data()
        rtsp-client<cb>::do_send_message()
            gstrtspconnection::gst_rtsp_watch_send_message()
                gstrtspconnection::gst_rtsp_watch_write_data()
                    gstrtspconnection::write_bytes()

It is in the rtsp-client.c function do_send_data() where the boolean return
value used to do keep-alive or not is set by

  return res == GST_RTSP_OK;

If gst_rtsp_watch_write_data() returns GST_RTSP_ERROR or GST_RSTP_EINTR, the
only effect, as far as have been understood, is that the do_keep_alive function
in gst_rtsp_stream_transport_send_rtp() will not be executed, which is what we
want. It only touches the rtsp session timeout.

And we want it so, because the BACKLOG constitutes a UNKNOWN delay in the
timeout. This unknown makes it hard to secure e.g. the failover use case,
saving a file locally.We can guess it, but it is not optimal. If we go on
preset, deterministic timeout values, we get a stream GAP. This is seen only in
TCP, not UDP.

It is reasonable that the RTSP timeout starts at the first possible moment
where it is seen that the connection may be down. 

Cheers.

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