[Bug 795396] 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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |slomo at coaxion.net
         Resolution|---                         |FIXED
   Target Milestone|git master                  |1.15.1

--- Comment #2 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
This is obsolete now with

commit 12169f1e845a45db41cc7d416ca0f101fa607176
Author: David Svensson Fors <davidsf at axis.com>
Date:   Thu Jun 28 11:22:21 2018 +0200

    Limit queued TCP data messages to one per stream

    Before, the watch backlog size in GstRTSPClient was changed
    dynamically between unlimited and a fixed size, trying to avoid both
    unlimited memory usage and deadlocks while waiting for place in the
    queue. (Some of the deadlocks were described in a long comment in
    handle_request().)

    In the previous commit, we changed to a fixed backlog size of 100.
    This is possible, because we now handle RTP/RTCP data messages differently
    from RTSP request/response messages.

    The data messages are messages tunneled over TCP. We allow at most one
    queued data message per stream in GstRTSPClient at a time, and
    successfully sent data messages are acked by sending a "message-sent"
    callback from the GstStreamTransport. Until that ack comes, the
    GstRTSPStream does not call pull_sample() on its appsink, and
    therefore the streaming thread in the pipeline will not be blocked
    inside GstRTSPClient, waiting for a place in the queue.

    pull_sample() is called when we have both an ack and a "new-sample"
    signal from the appsink. Then, we know there is a buffer to write.

    RTSP request/response messages are not acked in the same way as data
    messages. The rest of the 100 places in the queue are used for
    them. If the queue becomes full of request/response messages, we
    return an error and close the connection to the client.

    Change-Id: I275310bc90a219ceb2473c098261acc78be84c97

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