Skip to content

Client network loss causes stream freeze with UDP streams and a shared pipeline

Submitted by clo..@..il.com

Link to original bug (#761100)

Description

If a client suddenly loses network connectivity, then it can cause other clients to disconnect or their streams to freeze IF any one client us utilizing UDP.

This only happens on a shared pipeline, and with UDP as the only set transport.

Steps to reproduce:

  1. In gst-rtsp-server/examples/test-video.c, insert "gst_rtsp_media_factory_set_shared(factory, TRUE);" to line 136, and "gst_rtsp_media_factory_set_protocols(factory, GST_RTSP_LOWER_TRANS_UDP);" to line 137.
  2. Recompile the gst-rtsp-server examples (navigate to the root directory, and run make)
  3. Navigate to the example directory, and run the "test-video" shell script
  4. use ifconfig to get your eth0/wlan0 IP address
  5. Run the following command in a new terminal: "gst-launch-1.0 rtspsrc location=rtsp://<eth0/wlan0 IP address>:8554/test protocols=0x1 ! fakesink"
  6. Open a VLC client, and connect to the localhost IP address - rtsp://127.0.0.1:8554/test
  7. In another terminal, execute the following command: "sudo ip link set <eth0/wlan0> down"

This should cause the VLC client to quickly freeze it's current stream. The gst-launch-1.0 client will take some time before it disconnects, but during that time if you reconnect the VLC client to the localhost IP, the stream will continue.

There appears to be an issue with how UDP handles multiple clients on a shared pipeline. I can run any combination of UDP and TCP clients, and experience the issue if ANY one client loses their connection, even if that client is a TCP client. However, if the server is configured to only allow TCP connections, this issue never occurs.

Version: 1.6.0