[Bug 795396] New: rtsp-client: tunneled streams can stop streaming if client reads slowly and uses RTSP as keep-alive

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 795396
           Summary: rtsp-client: tunneled streams can stop streaming if
                    client reads slowly and uses RTSP as keep-alive
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-rtsp-server
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: branko.subasic at axis.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

When tunneling RTP, all data, rtsp, rtp, and rtcp, is written on the same
connection. The connection has a backlog where data is placed if it can not be
written on the socket immediately. The backlog is limited and when it's full
the thread trying to write will hang on a GCond until there's room in the
backlog again. So, if the rtsp client tries to send a response on a rtsp
command and the backlog is full the client thread will hang until signaled that
it can continue. Unfortunately, the callback function handling the signaling is
executed in the same context.

Some years ago a patch was made that circumvents the issue by opening up (i.e.
removing the limit) the backlog while serving an rtsp request, and limiting it
again when we're done. That was commit
404a80e38a508c13a9e9b7f9b1da70f3ccb2a77b.

However, that patch missed a few error cases. If authentication fails or the
rtsp version supplied by the client is wrong then we will send a response
before we make the backlog unlimited. Which results in the same deadloc if the
backlog is full.

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