Skip to content

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

  1. Start the rtsp video server with a shared media
  2. Launch a UDP RTSP client (for instance with vlc rtsp://...)
  3. Launch a TCP RTSP client (for instance with vlc --rtsp-tcp rtsp://...)
  4. Suspend the TCP RTSP client with kill -STOP pid

Expected Behavior

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

Solutions

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 create_and_plug_queue_to_unlinked_stream with 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.