<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [Live-devel] VLC Media Player and late
Out-Of-Order re</title></head><body>
<blockquote type="cite" cite><font face="Arial" size="-1">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.</font></blockquote>
<div><br></div>
<div>This is insane. There is something very broken in your
network.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial" size="-1">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.</font></blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">I decided to
probe the Live555 library in this case to study it behavior. And this
is what happens.</font></blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">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.</font></blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">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.</font></blockquote>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial" size="-1">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.</font></blockquote>
<div><br></div>
<div>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.</div>
</body>
</html>