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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Feb 7 04:23:10 PST 2011


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

--- Comment #28 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2011-02-07 12:23:05 UTC ---
Looks like that breath was not deep enough or the air not quite fresh ...
Anyway, here goes nothing ...

There may be some merit in the "not being hasty" approach/patch, if only as its
approach compares to the current one similarly to how
http://gentrans.sourceforge.net/docs/head/gst-entrans-plugins/html/gst-entrans-plugins-stamp.html
compares to stock videorate ;)

However, some other thoughts:
* after quite some comments given above on the "arbitrariness" of
drift-tolerance, another arbitrary parameter has now been sneaked in; a
non-configurable 1s (whereas e.g. stamp's sync-margin and sync-interval are
configurable, as is basesink's drift-tolerance)
* implementation problems (?): e.g. note the asymmetry in 
time - sink->priv->discont_time >= GST_SECOND
so what if time is that busted that it is not even advancing enough?  A better
measure might be the amount of samples that have "passed", and maybe the
current playback rate has to be kept in mind somewhere as well.

In summary, I would not mind such an approach, provided safe implementation,
and any new (few?) parameters are configurable, and preferably have defaults
that maintain current behaviour [*]

Also, btw, it is not quite hard to come up with broken timestamps
configurations that are not handled by current or patched approach, other than
maybe setting some parameters to "infinity" which pretty comes down to
operating in sync=false (so it's all at least partially academic anyway).

[*] even though some might consider the current one needs "fixing".
However, the above has precisely illustrated that render behaviour can and will
very well change, and while one might imagine it improves or has no ill effect
in some cases (e.g. a/v playback sync), it may or may not have a practical
impact in other cases (e.g. live voip).  That practical impact also has a
subjective aspect similar to sensitivity threshold for a/v sync etc, and as
such feel any messing with it should err on the side of caution.  Any
application is free to configure other values and/or to run with patched up
alternative defaults.

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




More information about the gstreamer-bugs mailing list