[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

Mark Nauwelaerts <mnauw> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mnauw at users.sourceforge.net

--- Comment #13 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2011-01-30 21:45:26 UTC ---
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.

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

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