[Live-devel] BUGS in rtsp interleaved

Cihan Kömeçoğlu cihan at thundernsi.com
Thu Jan 23 06:58:47 PST 2020


Hi Ross,

Yes as you said , there is a firewall and nat between client and server. 
thats why I have to use TCP.

I will increase send buffer size also and thinking to change sendTCP 
function to not fail even sendbuffer is full.


On 23.01.2020 16:29, Ross Finlayson wrote:
>
>> On Jan 23, 2020, at 1:32 AM, Cihan Kömeçoğlu <cihan at thundernsi.com> wrote:
>>
>> Hi Ross,
>>
>> Thanks for help and I solved the problem. The reason of problem is that RTPINTERFACE_BLOCKING_WRITE_TIMEOUT_MS value is not high enough and it causes failure send function in sendDataOverTCP.  Probably the root reason is poor network quality.
> Sigh…  By your own admission, your front-end stream’s output rate is exceeding the capacity of your network.  Then WHY, OH WHY are you trying to stream RTP-over-TCP on your front-end connection??
>
> Once again:
> If a RTP-over-TCP connection is so slow that it is eventually filling up the sender OS’s buffer, then that means that it’s exceeding the capacity of the TCP connection (which is based in part on the packet loss rate of the connection between the server and client; it can be *much* less than the nominal speed of your server’s network interface).  In this case it’s more efficient to stream over UDP instead.  Either way, you’ll get data loss, but the overall data loss rate will be less than it will be over the TCP connection.  Over TCP, the data loss will be clumped together (at the time(s) when the sender OS’s buffer keeps filling up), and the overall end-to-end latency (between sender and client) will be higher.
>
> Also, if you get to a situation where your OS’s output buffer is filling up, the LIVE555 code is forced to start using blocking I/O for many of its network packet writes.  This will cause the server to stall everything else that it might be doing.  In your case, you are experiencing stalls of up to ***500 ms***, which is crazy.
>
> As I have explained many times, one should stream over TCP *only if* you have a firewall - between the server and client - that blocks UDP packets. You should never stream over TCP just because you want to avoid data loss.  If your stream’s data rate exceeds the capacity of the network connection (server->client), then you *will* lose data, no matter how you choose to stream it.  But it’s much better to stream over UDP.  However, if you really want to avoid all data loss, then you should be copying your data using something like HTTP, rather than streaming it.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel


More information about the live-devel mailing list