[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 #9 from Felipe Contreras <felipe.contreras at gmail.com> 2011-01-30 16:09:39 UTC ---
(In reply to comment #8)
> (In reply to comment #4)
> > So, if virtually every player out there plays this clip (at least all the ones
> > I've tried, and I've tried a lot), that means they all are wrong? GStreamer is
> > the only one right? I don't think many people out there would agree with that.
> 
> Have you considered the possibility that it's not about being right or wrong,
> and that both in fact may be "right", albeit approaching matters with a
> different focus, use-cases etc, and that in GStreamer's case it is at least
> configurable.

Not really. There is such thing as right and wrong, and if you play this clip
with Totem (or any other GStreamer player) it sounds wrong. So, somebody has to
be wrong, either GStreamer, Totem, or the clip.

> In particular, this clip (or any one with broken [*] input timestamps), along
> with the fact that tolerance may have been 500ms at one point in time only
> suggests that one (= application) might consider increasing the tolerance to
> 100ms or 500ms or for that matter "infinity" if it really wants to support
> playback of broken _audio-only_ clips.
> 
> Other considerations and available facts, such as all other non-broken stuff
> playing just fine with 40ms (= default) and a/v lip-sync sensitive to (afaik)
> 100ms variations indicate the present default is fine.
> 
> In summary, the default, which by definition should Just Work (safely) for
> majority (-> not necessarily all) of use-cases and inputs is best to stay as it
> is, but it could be considered to have playbin2 tweak the drift-tolerance in
> some circumstances (e.g. single audio stream playback) (rather than relaying
> this to application using it, which can already configure so at present if
> desired).
> 
> 
> [*] definition of broken: providing an imperfect stream of timestamps, with
> imperfection in order of magnitude way beyond (single sample) rounding errors.

Certainly 40ms is way beyond rounding errors, isn't it? So why 40ms? Why not
20ms, or 10ms? Because 40ms is needed for some clips, well, it turns out 100ms
is needed for some clips too.

So, what is "wrong" or unsafe with 100ms? Would it have any negative impact? Is
anybody relying on this value being low? Well, it was 500ms at some point in
time, so we know the world is not going to end. In fact, it has changed from
500ms to 20ms, to 40ms, with little explanation, and even mismatching comments.
So, my bet is that nobody really cares about this value.

Now, is the clip broken? Well, how can it be if every player out there plays
it. You claim it's broken because the timestamps drift beyond rounding errors,
but GStreamer is already playing broken clips (>10ms drift). So, this
definition of broken doesn't seem to matter for people outside GStreamer, and
it's not very practical in GStreamer either, as the drift tolerance has changed
over the years, never matching this idealistic definition. So no, the clip is
not broken for any practical purposes (maybe academic).

Are the applications broken? Well, do you seriously expect all applications to
change the drift tolerance in order to play these kinds of clips? (including
gst-launch) I would say applications would find that preposterous. They would
like GStreamer to just play the clip, just like every other framework.

I think you should consider the possibility that the drift-tolerance is just
too low, and that increasing it would not cause any harm (otherwise why was it
500ms before).

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