[Bug 761100] New: Client network loss causes stream freeze with UDP streams and a shared pipeline

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=761100

            Bug ID: 761100
           Summary: Client network loss causes stream freeze with UDP
                    streams and a shared pipeline
    Classification: Platform
           Product: GStreamer
           Version: 1.6.0
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-rtsp-server
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: clowd81 at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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.

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