[Bug 711593] New: [rtpjitterbuffer] receiving a not very old packet could make it unnecessarily reset

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=711593
  GStreamer | gst-plugins-good | git

           Summary: [rtpjitterbuffer] receiving a not very old packet
                    could make it unnecessarily reset
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: julien.isorce at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.