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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #4 from Jason Litzinger <jlitzinger at control4.com> ---
The test demonstrates the problem, but from your reply it sounds like waiting
for the new deadline is expected behavior?  

I considered the second wait to be incorrect (which can be substantial in some
cases) because I inferred that the purpose of the deadline timer was to enforce
the initial latency.  By sync'ing on a new timeout, data is buffered for longer
than the latency.

Additionally, if ts-offset is large (say seconds), the additional time
buffering may be substantial.  

For example  (Assume the jitterbuffer is configured for buffer-mode=0 where the
timeline is controlled by the RTP timestamps):

When a client joins a session already in progress, it won't be sync'd to the
media timeline until it receives the first SR RTCP packet.  Once the SR comes
in and is processed, the ts-offset can be added to the PTS of each outgoing
buffer to ensure it's timestamp reflects its correct position in the media
timeline.

If the case where the SR comes in before the latency expires, the deadline
timer is extended, delaying the first buffer longer than the desired latency. 
Is that the desired effect?

If so then my understanding is wrong and it's likely that at least #1 is a
non-issue and can be closed out.

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