[Bug 729524] New: If retransmissions enabled, a gap larger than the latency can result in a stuck jitterbuffer.

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Sun May 4 10:22:34 PDT 2014


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

           Summary: If retransmissions enabled, a gap larger than the
                    latency can result in a stuck jitterbuffer.
    Classification: Platform
           Product: GStreamer
           Version: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: jlitzingerdev at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=275833)
 View: https://bugzilla.gnome.org/attachment.cgi?id=275833
 Review: https://bugzilla.gnome.org/review?bug=729524&attachment=275833

Test case to demonstrate issue.

Observed in git master and the 1.2 branch.

Test case and sample fix patches attached.  A description of the steps that
trigger the stuck buffer are:

1.  seqnum 0 arrives, seqnum 1 expected
2.  seqnum 1 arrives, seqnum 2 expected
3.  Data stops arriving, RTX requests sent for seqnum 2 until it is finally
declared lost.
4.  lost event for seqnum 2 is pushed, incrementing next_seqnumi to 3.
5.  Seqnum 16 arrives, packets 2->6 are part of a single "lost" event.
6.  RTX packets begin arriving with seqnum 8
7.  Lost event from 5 is popped to be pushed, but seqnum 2 < next_seqnum (3),
so it is dropped.
8.  jbuf is now stalled forever. 

The problem is that for large gaps, calculate_expected creates the "bulk" (for
lack of a better word) lost event starting at a seqnum that has already been
declared lost.  This doesn't happen if RTX is disabled, but will stall the
buffer if enabled.

-- 
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.


More information about the gstreamer-bugs mailing list