[Live-devel] Slow connection problem with RTP over RTSP/TCP

[mproxi at orangemail.sk]

>No, this is nonsense.  TCP is intended to be a reliable
>byte-stream protocol; it's the job of the operating system's
>TCP implementation - not application-level code (such as 
>LIVE555) - to provide reliable delivery.  

Yes it is true, but problem is that LIVE is loosing the data, not the OS. LIVE is using non blocking sockets. If you are unable to send data, send() returns with number of data send and you discard the rest. That implementation would work for blocking sockets, because you are guarantee to really send the data, but not here.

This generate traffic on the network, but as packet are discarded randomly, you must discard many incomplete frames on the client, so much of the network traffic is wasted.

>If, however, your stream's bitrate is too large for your 
>network, then you're inevitably going to get packet loss 
>(usually because an OS buffer in the sender OS will 
>overflow).  There's nothing you can do to avoid this.  If your
>stream's bitrate is really too large for your network, then you 
>should not be sending it (and you should certainly not be 
>sending it over TCP).

In some cases you can change bitrate of the video by changing framerate. So you can save the day even if original setup was unsuitable for network bandwidth. This is true if you are compressing video on the fly and do not care, that much about framerate.

>If, however, your stream's *average* bitrate is within the
>capacity of your network, you can reduce the probability of
>your server OS's 

I have very  little knowledge about portability, but I can think, you can support it at least for some OS, by #ifdef.

>Note that we provide a function "increaseSendBufferTo()" that 
>does this.  Our RTSP server implementation - by default - 
>sets this buffer size (for each server and stream socket) to 
>50 kBytes (search for "increaseSendBufferTo" in the code).  
>However, you could use a larger value this (e.g., by 
>subclassing "RTSPServer").

"Free size" of the OS buffer is dependent also on the TCP window size on the server and on the client, so you have no power over "free size" in OS buffer.

Martin

>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