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

[Guy Bonneau]

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.
 
>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.
 
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.
 
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. 
 
First glitch:
 
>From this point the only recovering mechanism that will reenable
ReorderingPacketBuffer::getNextCompletedPacket to return packets is the
timeout defined by fThresholdTime. After the timeout period then
fNextExpectedSeqNo is redefined to the sequence number of the late
out-of-order packet.
 
Second glitch:
 
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
ReorderingPacketBuffer::getNextCompletedPacket checks the fNextExpectedSeqNo
that is set to the late out-of-order packet.
 
Again the only recovering mechanism that will reenable
ReorderingPacketBuffer::getNextCompletedPacket to return packets is the
timeout defined by fThresholdTime
 
Thus 2 successives time-out occurs with an in between releases out-of-order
packet. This give an hard time to the application VLC
 
Relinking the VLC application with a new seqNoThreshold set to 300 really
improved the smoothness of the video playback.
 
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.
 
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.
 
1- 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.
 
2- 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.
 
Regards
Guy Bonneau
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081114/8998f446/attachment.html>