[Bug 745539] New: Applying ts-offset to deadline timer can result in a stalled jitterbuffer.

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=745539

            Bug ID: 745539
           Summary: Applying ts-offset to deadline timer can result in a
                    stalled jitterbuffer.
    Classification: Platform
           Product: GStreamer
           Version: 1.4.1
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: jlitzinger at control4.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Discovered in 1.4.1 but, based on code inspection, I see no reason it won't
happen in master.

Two scenarios illustrate the issue (assume no lost packets for simplicity),
retransmissions enabled.

1.  Simple case:  No upstream timestamping, so no expected timers are queued.  
- First packet comes in, dts zero, deadline timer timeout is equal to the
latency.  Because there are no expected timers, this is the only timer.

- wait_next_timeout() syncs on the deadline timer.

- SR comes in, resulting in a modification to ts-offset.

- Sync completes, wait_next_timeout() returns to the top of the loop and 'now =
latency'.

- When get_timeout() is called for the timer that was just used for sync, the
timeout value is now different (and wrong) because ts-offset is added.
- timer_timeout !< now (even though we just sync'd on this timer)

stuck

2.  Upstream timestamping, expected timers are queued.
- First packet comes in, dts zero, deadline timer timeout is equal to the
latency.  Because there are no expected timers, this is the only timer.

- wait_next_timeout() syncs on the deadline timer.
- Next packet comes in, sync on deadline is unscheduled.  Best timer is now the
expected timer for the next packet (ok because latency has not been exceeded
yet).
- SR comes in, resulting in adjustment to ts-offset.

>From this point forward, EXPECTED timers will outrank the deadline timer until
the DTS on incoming packets exceeds the deadline timer's timeout (pretty sure
until ts-offset elapses).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.