[Live-devel] Help: cause of RTP packet loss

[Ross Finlayson]

First, note that, in your case, the 'reordering buffer threshold' is 
a complete 'red herring'.  That becomes relevant only when you have 
out-of-order packets in the network.  On a LAN, it's very unlikely 
that any packets are out-of-order, so you should leave this threshold 
at its default value (100ms).

The key pieces of information in your message are:
1/ If you play the stream using VLC, you don't seem to lose any packets.
2/ If you record the stream using openRTSP, you seem to lose packets.

Note also that the incoming packets are getting dropped before they 
even reach the LIVE555 RTP reception/handling code, so no amount of 
messing with that code is going to help things.

Because the client RTSP code (the "LIVE555 Streaming Media" 
libraries) is the same in both cases, and because your socket receive 
buffer is at least as large as that (2000000) used by VLC, the 
difference has to be related to the fact that in case 2/, you're 
writing the incoming data to a file, rather than feeding it to 
decoding/rendering software.

So I suspect that occasionally, on your OS, writes to a file are 
blocking for a sufficient amount of time to cause incoming RTP 
packets to overflow some internal buffer and get dropped within the 
OS.  I don't know why this would be happening, but perhaps disk 
seeking is to blame, in which case you could check to see whether you 
can (somehow) increase your OS file system's write-ahead buffering.

Anyway, you can test this hypothesis by running
	openRTSP -v rtsp://whatever > /dev/null
i.e., by discarding the incoming data rather than writing it to a 
file, and checking (from RTCP reception reports) whether or not you 
still see packet loss.

If that doesn't shed any light on your problem, then I don't know 
what else could be going wrong.  Sorry.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/