[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 #5 from Wim Taymans <wim.taymans at gmail.com> ---
(In reply to Jason Litzinger from comment #4)
> The test demonstrates the problem, but from your reply it sounds like
> waiting for the new deadline is expected behavior?  

It is, after all the latency of the jitterbuffer was increased so we have more
time to wait for missing packets.

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

yes, if you don't do that, your buffer will be out-of-sync.

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