gst-rtsp-server: not able to send big frames for 2 clients both using rtsp over tcp in low bandwidth network
Hi,
I'm using gstreamer 1.20.2. and come across a problem about rtsp over tcp.
I add a shared media factory to rtsp-server for a h.264 stream. And there are 2 clients that will access the stream by rtsp over tcp and the network has low bandwidth(100Mbps network). When the first client accesses the stream from the server choosing rtsp over tcp, it works correctly. Then the second client accesses the same stream by rtsp over tcp, it will work correctly only while the frame size is not big. When there is a large I frame that has size over 200KB sent to both clients, the following log shows:
0:10:04.842062023 420 0x1a5a790 DEBUG rtspclient rtsp-client.c:4908:do_send_messages:<GstRTSPClient at 0x7574c430> wait for message 1, channel 0
And the server stops sending frames to second client after the large I frame sent, while the server continues to send frames to the first client.
After investigation, I found that:
When rtsp server send rtp/rtcp data over tcp, the tcp send thread(created in handle_new_sample()) calls send_tcp_message(). It will push rtp/rtcp buffer to each transport's backlog and then calls check_transport_backlog() to pop buffer from backlog queue and push buffer to client. If the buffer can't be sent completely in a single push_data() call, the buffer will be queued and continued to send in client watch thread. And if the transport is still sending the buffer in client thread, next time calling push_data() in the tcp send thread will get return value false. Then the transport will be removed and the rtp/rtcp data will not be able to be sent thereafter.
Also I found that when the backlog queue mechanism was introduced, in send_tcp_message(), the backpressure is checked using gst_rtsp_stream_transport_check_back_pressure() before calling push_data(). If there is a buffer queued in client watch(the backlog), the new buffer will not be pushed to client and will be pushed into backlog queue.
According to my understanding, the check mechanism might be the possible solution to this situation. But I am not sure the reason why it is removed now. Would you please help to take a look and advise the next step? Thank you.
related commit: gst-rtsp-server@dd32924e