[Bug 770934] New: Gap between last transmitted frame and failover connloss buffer saved file in RTSP/TCP

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Sep 6 09:22:34 UTC 2016


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

            Bug ID: 770934
           Summary: Gap between last transmitted frame and failover
                    connloss buffer saved file in RTSP/TCP
    Classification: Platform
           Product: GStreamer
           Version: 1.9.2
                OS: Linux
            Status: NEW
          Severity: major
          Priority: Normal
         Component: gst-plugins-base
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: opaque.se at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

When streaming over RTP/RTSP/TCP, and loosing network connection, there is a
RTSP TIMEOUT triggered to run.

When there is congestion or otherwise some problem with the network, a watch
BACKLOG is used to store messages intended for send. In the case of a
disconnect, the queue will fill up, but it take a few moments (queue size set
to e.g. 100). 

The issue is that during the use of the BACKLOG queue, the keep-alive is still
handled, although there are no connection. This means that the RTSP TIMEOUT
(60+5s) is touched and reset at the keep-alive and not allowed to run until
after up to several seconds have passed, and the queue is full. 

It would be natural that the RTSP TIMEOUT is allowed to run at the first
possible moment there is an indication of LOSS, like the RESOURCE TEMPORARILY
UNAVAILABLE indication from the non-blocking write socket when it receives
EWOULDBLOCK in the function write_bytes().

The impact is that functionality depending on deterministic values of the time
delay between the last frame of the lost stream and the timeout expiration,
will have a hard time bridging that gap. (e.g. fail over file save locally)

This manifest itself only in TCP not in UDP.

A patch has been prepared that addresses this issue.

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