<div dir="ltr">Hi. I use live555 to create server and client that stream and get video and audio respectively. I use RTP over TCP due to possible bad network. If use UDP instead of TCP then in some situations can't get I-frames of H264 stream and nothing is decoding, showing etc, I can't afford this in my system. I can afford some lags, gaps and so on but not "nothing". <br>If the callback from my MediaSink on the client side is working fast then everything is OK. However if it hangs for example for 1-2 seconds it is possible that some internal socket buffer becomes overwhelmed. If the server is not live555 based server then after such lag it is recovered and continues working. But the live555 server stops sending video and continues sending only audio. <br>I set DEBUG and DEBUG_SEND defines when compiling live555 server and found out that the problem is in 'sendRTPorRTCPPacketOverTCP' and 'sendDataOverTCP' method in RTPInterface class. <br><br>I got the essence of the algorithm:<br>1) Send header of packet. If sending failed then do nothing;<br>2) If successful then force send the packet's body.<br>3) If the full body didn't send then the stream got the inconsistent state (client got header but only part of body). The question is: what to do with such a state? <br><br>Current live5555 code just closes video's streaming. And as for me this is illogical for the next reason.<br>The live555 client can recover (don't know how but it is cool) from such inconsistent packet's data and continue to get video and audio in the correct way. It does it with other servers and can do it with live555 server if comment 'removeStreamSocket(socketNum, 0xFF);' on 412 line of RTPInterface.cpp. <br><br>So, I propose not to close video streaming in such cases (remove that line). Thanks.<br></div>