ulpfec correction is obviously useless when receiving a stream
over TCP, and in TCP modes the rtp storage receives non
timestamped buffers, causing it to queue buffers indefinitely,
until the queue grows so large that sanity checks kick in and
warnings start to get emitted.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/149>
This ensures we don't end up calling any of transports' callbacks
with a potentially unreffed user_data (in practice, a client that
may have been removed)
Fixes#97
We cannot hold stream->lock while pushing data, but need
to consistently check the state of the backlog both from
the send_tcp_message function and the on_message_sent function,
which may or may not be called from the same thread.
This commit introduces internal API to allow for potentially
recursive locking of transport streams, addressing a race
condition where the RTSP stream could push items out of order
when popping them from the backlog.
The internal index of our appsinks, while it can be used to
determine whether a message is RTP or RTCP, is not necessarily
the same as the interleaved channel. Let the stream-transport
determine the channel to check backpressure for, the same way
it determines the channel according to whether it is sending
RTP or RTCP.
The previous implementation stopped sending TCP messages to
all clients when a single one stopped consuming them, which
obviously created problems for shared media.
Instead, we now manage a backlog in stream-transport, and slow
clients are removed once this backlog exceeds a maximum duration,
currently hardcoded.
Fixes#80
