TCP Consumers of a Shared Media Factory can block video delivery to other consumers of the same mount point.
Using the gst-rtsp-server example test-launch.c, it is possible for a misbehaving TCP consumer to stop playback to other TCP consumers of a shared media factory.
To replicate the issue;
Launch test-launch with pipeline "videotestsrc ! x264enc ! rtph264pay name=pay0 pt=96"
Consume the stream with 2 ffplay clients with command;
ffplay -loglevel trace -rtsp_transport tcp rtsp://127.0.0.1:8554/test
Attach to one ffplay process using gdb so the process is paused.
Observe the second ffplay process stops playback.
The issue seems to be in rtsp-stream.c In the func send_tcp_message(), there is a variable that will be increased.
priv->n_outstanding += n_messages * priv->n_tcp_transports;
Then in the func on_message_sent(), that variable should be decremented
priv->n_outstanding--;
In the case where we paused the ffplay process with gdb, on_message_sent() is not called & the variable never decrements.
The result is seen in handle_new_sample() callback, where a decision is made to send another tcp message only when
if(priv->n_outstanding == 0)
This means no more data for any of the clients of that shared media.