[Bug 648463] pipeline stalls when using gst_rtsp_media_factory_set_shared (factory, TRUE) && vlc

[GStreamer (GNOME Bugzilla)]

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

clowd81 at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clowd81 at gmail.com

--- Comment #13 from clowd81 at gmail.com ---
I've been encountering a similar issue.  I'm not sure if it's related or not to
this one, and I've opened a new bug for it at
https://bugzilla.gnome.org/show_bug.cgi?id=761100, but I'm copying the info
here in case it is related.

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.

I have uploaded a video showing this to my dropbox here:
https://www.dropbox.com/s/2ryew9npz5lja5f/gst-rtsp-server-udp-bug.webm?dl=0

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