TCP RTP streams blocks UDP streams for shared media
With the changes introduced in !80 (merged) gst-rtsp-server streams shared media at the pace of the slowest tcp stream, which works well when only TCP RTP streams are served, but when UDP RTP streams join the mix they are also slowed down to the speed of the slowest TCP stream. In the extreme case a hung TCP RTP client can bring down streaming for all the connected UDP clients.
Steps to reproduce
- Start the rtsp video server with a shared media
- Launch a UDP RTSP client (for instance with
- Launch a TCP RTSP client (for instance with
vlc --rtsp-tcp rtsp://...)
- Suspend the TCP RTSP client with
kill -STOP pid
I guess there are multiple "correct behaviors". For live media we want to consume the data as fast as possible so the other consumers are never blocked and either drop frames or remove TCP clients which stream too slow. For recorded media we want to consume the stream at the speed of the fastest consumer (including the UDP ones).
My first attempt was to always return true from
any_transport_ready. In theory
gst_rtsp_stream_transport_check_back_pressure should return the correct result for UDP streams, but I don't know why this is not the case. This didn't work correctly as the TCP stream was very jumpy.
The quick fix for our case was making the queues created in
g_object_set (*queue, "leaky", 2, NULL); instead of setting the buffer sizes to 0. This approach probably has issues with non-live sources like videotestsrc which generates a lot more than 30 fps.