[Live-devel] Rare 2s "delay" when viewing live streams

[Erlandsson, Claes P (CERLANDS)]

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/ 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130716/a511df20/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5739 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130716/a511df20/attachment.bin>