Thanks for the confirmation Ross.
We do use UDP, i.e. the default, which makes this lag so very strange. I can clearly see all frames being received on the first UDP-port (when viewing ports in use with e.g. TCPView). This 2s lag has been observed three times in total over the last four months, on different workstations. However, each test-workstation cycles through a lot of streams, each typically making around 100,000 connections a day, so it's a very rare occurrence. The fact that it continues to happen once it started, i.e. for every subsequent connection using the same event loop/video pane is even more confusing. /Claes Of course our code doesn't buffer anything for 2 seconds. (The 'packet reordering' queue delays incoming packets for at most the 'packet reordering threshold' - which is, by default, only 100 ms - and only if packet loss occurs.) The delay is obviously caused by the TCP implementation - i.e., in the OSs of your server and client. This is not a bug; this is simply TCP's way of ensuring reliable data delivery, in the face of high data rates and lossy networks. To overcome this, either send less, or stream via UDP instead of TCP. (You should stream RTP-over-TCP *only* if there's a firewall - between the server and client - that blocks UDP packets.) Ross Finlayson Live Networks, Inc. http://www.live555.com/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
