<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16735" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2>While
experimented with a Mpeg2 video that I streamed to the
internet using a Live555 sample application from work to home I
found that the VLC media player struggled from time to time to resync the video.
This was visible by some freezing and restarting of the video on the live window
displayed by VLC. But overall the video playing was a very pleasant experience
notwithstanding a resync from time to time. Thanks to the live555
library.</FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2>From an academic
point of view I was wondering about how much packet was lost from work to home!
How much packets was received out of order and so on! I was also interesting to
study the resync issue and try to correlate with the packet losses. Thus I
decided to use Wireshark to capture many sessions of the RTP stream and the RTSP
session while VLC was playing the received video.</FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2>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. Which seemed to be a very long delay. But this is
internet.</FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2>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
<FONT size=2>of an out of order packet is greater than this
threshold.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2>I decided to probe
the Live555 library in this case to study it behavior. And this is what
happens.</FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2>Once a late
out-of-order packet is received with a <FONT size=2>seqNoThreshold (100)
condition being True then the method <FONT
size=2>ReorderingPacketBuffer::storePacket accept the packet. Note that <FONT
size=2>fNextExpectedSeqNo is not reinitialized at this point. In most cases
storePacket method will redefine fHeadPacket with the late received
out-of-order packet.</FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2>Thus the following
received packets after the received out-of-order packet will be keep on hold
because the method <FONT size=2>ReorderingPacketBuffer::getNextCompletedPacket
check the condition <FONT size=2>fHeadPacket->rtpSeqNo() ==
fNextExpectedSeqNo. And fHeadPacket is the out-of-order late received packet.
</FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2>First
glitch:</FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2>From this point the
only recovering mechanism that will reenable
ReorderingPacketBuffer::getNextCompletedPacket to return packets is the timeout
defined by <FONT size=2>fThresholdTime. After the timeout period then <FONT
size=2>fNextExpectedSeqNo is redefined to the sequence number of the late
out-of-order packet.</FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2>Second
glitch:</FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2>Then
ReorderingPacketBuffer::getNextCompletedPacket returns the late out-of-order
packet. But the new redefined fNextExpectedSeqNo to the late out-of-order packet
prevent the "in-order" next received packets from being returned by
ReorderingPacketBuffer::getNextCompletedPacket. From now on the "in-order"
received packets will be keep onhold because the method <FONT
size=2>ReorderingPacketBuffer::getNextCompletedPacket checks the
fNextExpectedSeqNo that is set to the late out-of-order
packet.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2>Again <SPAN
class=307471822-13112008><FONT face=Arial size=2>the only recovering mechanism
that will reenable ReorderingPacketBuffer::getNextCompletedPacket to return
packets is the timeout defined by <FONT
size=2>fThresholdTime</FONT></FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008></SPAN></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008>Thus 2 successives time-out occurs with an in between
releases out-of-order packet. This give an hard time to the application
VLC</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008></SPAN></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008>Relinking the VLC application with a new seqNoThreshold
set to 300 really improved the smoothness of the video
playback.</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008></SPAN></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008>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.</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008></SPAN></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008>My feeling is that some revisiting to the
ReorderingPacketBuffer::storePacket storing algorithm would improve the
behavior of resync issue when late out-of-order packets are received. I have 2
suggestions.</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008></SPAN></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008>1- </SPAN></FONT></SPAN><SPAN
class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008>I'm not sure why the threshold of 100 was choosen for
seqNoThreshold . There must be an historical issue that I do ignore. But I would
suggest to add an API to let an application be able to change that value the way
it is possible to an application to change fThresholdTime. Then by exposing that
value in an application like VLC it would be possible to fine tune the
application to the internet behavior.</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008></SPAN></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008>2- </SPAN></FONT></SPAN><SPAN
class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008>If a late out-of-order packet is accepted by
ReorderingPacketBuffer::storePacket then fNextExpectedSeqNo could be
reinitialized to the new late out-of-order sequence number thus preventing a
double glitch. Only a single timeout would occur.</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008></SPAN></FONT></SPAN> </DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008>Regards</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008>Guy Bonneau</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=307471822-13112008><FONT face=Arial size=2><SPAN
class=307471822-13112008></SPAN></FONT></SPAN> </DIV></BODY></HTML>