[Live-devel] VLC Media Player and late Out-Of-Order received packets by Live555

[Ross Finlayson]

>After asking Wireshark to analyze the stream I was dumbfounded 
>looking at the result. In fact there were no packet losses for those 
>sessions. But about .05% of packets were delayed by about 150-250 
>RTP packets. Giving that I was streaming the video at 1.5 Mbits/Sec 
>I estimated that the delay of these packets were about 1 to 2 
>seconds.

This is insane.  There is something very broken in your network.


>After pondering with the statistic It struck me that the Live555 
>library set a constant threshold of reordering packet at 100 and 
>accept a delayed packet if the sequence number of an out of 
>order packet is greater than this threshold.
>
>I decided to probe the Live555 library in this case to study it 
>behavior. And this is what happens.
>
>Once a late out-of-order packet is received with a seqNoThreshold 
>(100) condition being True then  the method 
>ReorderingPacketBuffer::storePacket accept the packet. Note that 
>fNextExpectedSeqNo is not reinitialized at this point. In most cases 
>storePacket method will redefine fHeadPacket with the late received 
>out-of-order packet.
>
>Thus the following received packets after the received out-of-order 
>packet will be keep on hold because the method 
>ReorderingPacketBuffer::getNextCompletedPacket check the condition 
>fHeadPacket->rtpSeqNo() == fNextExpectedSeqNo. And fHeadPacket is 
>the out-of-order late received packet.

The test against "seqNoThreshold" was intended - long ago - only as a 
sanity check against really messed up streams, and probably never 
actually got satisfied for anyone else, because noone ever had a 
stream as messed up as yours :-)  You're right - it's basically just 
a historical artifact that I had forgotten about.

As you noted, accepting such excessively delayed packets causes 
problems (that I hadn't really anticipated), so because of this, the 
best thing to do would be to just remove this test altogether.  I'll 
make this fix in the next version of the code: From now on, *all* 
out-of-order packets (except those received within "fThresholdTime" 
microseconds) will be discarded.


>I understand I could have increased the fThresholdTime to a value of 
>2-3 seconds to solve the problem. But for the kind of applications I 
>am looking on this is out of specification.

You should really look into why some packets are getting delayed this 
much.  This is far in excess of what people normally see on the 
Internet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081115/b10d5006/attachment.html>