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.