[gstreamer-bugs] [Bug 640859] basesink default drift-tolerance causes glitches on some clips

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #14 from Felipe Contreras <felipe.contreras at gmail.com> 2011-01-31 05:24:33 UTC ---
(In reply to comment #13)
> I feel the above approach (variations) are problematic.
> 
> Fiddling in the/a decoder has us (d)evolving from parameter tuning to adding
> stuff to a (all?) decoders.  In particular, this code will have decoders impose
> their view on what is a correct timestamp and doing so independently in
> separate parts of the pipeline (e.g. consider audio and video case).  Moreover,
> as it is more intrusive (as mentioned) a single glitch will have a decoder not
> giving a toss about demuxer timestamp and carry on on its own, while another
> decoder is possibly doing the same, though (ts wise) differently.  All in all,
> no telling what it will do to a/v sync (as it removes information very much
> upstream, rather than giving downstream (sink) a chance to evaluate real info
> (e.g. demuxer ts) versus "natural next").
> 
> Doing similar stuff in baseaudiosink alleviates some of the above, but also
> plainly shows this is a nasty hack as it introduces inherent asymmetry.  That
> is, if incoming ts is earlier than expected natural, we totally disregard it (=
> basically infinite drift-tolerance on this side), and otherwise we consider
> threshold.

I agree.

> So what to do next when a clip comes by whose timestamps are way too far apart
> (such are available at hand).  The same approach should then introduce infinite
> tolerance on the other side, and we are back where we started (should stay),
> i.e. tweaking with the tolerance parameter.
> 
> Let's take a deep breath, shall we ...

The issue is very simple; when shall a resync happen? The assumption so far has
been that we do want resyncs to happen, but do we? If so, when?

Presumably, when the audio is drifting too much. Personally, I find a drift of
even 200ms barely noticeable. So, an a/v sync drift of 100ms might be
preferable than an audio skip. Or maybe not _if_ there's only *one* skip.

I tested a constant drift of 100ms, and that works fine, as only one resync
would happen. The problem is when going in and out of the 40ms threshold; a
sequence of drift 0, 40, 0, 40... Would cause the audio to be totally crappy.

Strictly speaking there is no "drift". 0, 10, 20, 30, 40, 50... _That_ would be
drift.

I'm sending a patch that does differentiate drift from random timestamp
variation.

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