GNOME Bugzilla – Bug 711593
rtpjitterbuffer: receiving a not very old packet could make it unnecessarily reset
Last modified: 2013-11-11 16:06:15 UTC
If packets seqnum_11 and seqnum_200 are in the jitter and then you get seqnum_10, it actually make the jitter to reset (flush its content and remove all the timers). Packet seqnum_10 is late but if then you get seqnum_199, seqnum_201 etc ... then seqnum_10 is just maybe an exception and I think it should not make the jitter to reset. But it seems that's not what the spec example suggests. Also when retransmission is activated, in our example you get seqnum_10 which cause a reset and then you get seqnum_199. It will make the jitter to ask retransmission for every packets from seqnum_11 to seqnum_198. It's a lot of unnecessary requests. Moreover the jitter may have already contain most of those packets before being reseted. To determine if the packet is very late or not, currently the jitter computes the distance between this late packet with the most recent packet in the jitter. Then it compares this distance to RTP_MAX_MISORDER (=100). An other approach could be to compute the distance between this late packet with the oldest packet in the jitter. In our example it will cause to just drop the packet seqnum_10 but it will not make the jitter reset. And also avoid to send all those requests in case of retransmission if another late packet follows. Also I think if the jitter get seqnum_12 in our example, instead of seqnum_10, without the new approach it will also make the jitter to reset. With the new approach it will not make the jitter to reset and it will not drop the packet.
Created attachment 259169 [details] [review] only reset if the packet is really too old
I would prefer not to change the behavior of this check. We currently do it like suggested by the spec. The idea is that in a typical network, you can't have packets being reordered 100 seqnums, this is only based on network conditions and has nothing to do with jitterbuffer size. Changing this would, for example, cause problems with very high rate streams, like uncompressed video. In those cases, the seqnum wraps around in 0.5 seconds and the check against the oldest packet would not make sense anymore because you could have multiple wraparounds in the buffer.