[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 #26 from Felipe Contreras <felipe.contreras at gmail.com> 2011-02-01 01:16:28 UTC ---
(In reply to comment #25)
> (In reply to comment #24)
> > You would hear glitches all the time, because basesink would do
> > resynchronization every buffer and apparently GStreamer timestamps have a
> > jitter of around 100us, while FFmpeg has 10ms.
> 
>   Congratulations, you've just proven that the default 40ms is a better choice
> than 100microseconds. I applause your logic. Wait, you had a point ?

Wrong.

40ms is not _better_ than 100us, or 10ms. Compared to 10ms, 40ms should give
you 4 times less resyncs, but each resync would be 4 times bigger.

That's not what is happening. 10ms gives you total crap on some clips. I would
gladly post a clip encoded with FFmpeg that shows that.

>   The moment you'll understand that drift-tolerance is called as such because
> it's the threshold at which we consider timestamp inconsistencies as *drift*
> and not as *jitter* you might be able to [censored] the [PG rated]. Both
> Olivier and Mark have proven their understanding of this problem in their
> comments, but you insist in childing around.

Olivier didn't say anything, just asked questions, and Mark hasn't even
commented anything after my last patch. Maybe you have some ad hominem thing
going on here.

Here is the proof that the issue has nothing to do with demuxers. I'm running a
simple audiotestsrc ! dummyfilter ! pulsesink pipeline showing all the possible
scenarios (I'll attach the source code). I am simply printing the calculated
diff from expected and incoming timestamps, and when a discont happens.

This also shows that my patch doesn't affect any other scenario negatively.

== Currently ==

1) No drift, low jitter (drift=0 jitter=100)

    diff=5
    diff=0
    diff=5
    diff=0

Ok

2) High drift, low jitter (drift=20000 jitter=100)

    diff=877
    diff=1764
    discont
    diff=877
    diff=1764
    discont

Ok (discont happening at the expected times)

3) No drift, high jitter (drift=0 jitter=40000)

    diff=1765
    discont
    diff=1764
    discont
    diff=1764
    discont
    diff=1764
    discont

Total crap

4) High drift, high jitter (drift=20000 jitter=40000)

    diff=883
    diff=1763
    diff=881
    diff=3527
    discont

Ok (the drift is hidden a bit, but catched eventually) (different values would
make this fail as 2))

== Patch ==

1) No drift, low jitter (drift=0 jitter=100)

    diff=5
    diff=0
    diff=5
    diff=0

Ok (same)

2) High drift, low jitter (drift=20000 jitter=100)

    diff=877
    diff=1764
    diff=2641
    discont
    diff=887

Ok (discont happens a bit later)

3) No drift, high jitter (drift=0 jitter=40000)

    diff=1765
    diff=1
    diff=1765
    diff=1

Ok (Not crap any more)

4) High drift, high jitter (drift=20000 jitter=40000)

    diff=883
    diff=1763
    diff=881
    diff=3527
    diff=2645
    discont

Ok (the drift is again delated a bit) (6 buffers just to show that) (different
values would not affect negatively)

You keep saying that this somehow breaks the current behavior but you don't say
how. These are the only 4 possible scenarios, and I've done all I can to
reproduce them. It would be productive of you to at least mention a scenario
that might get broken.

Now, you can play around with this scenario and see for yourself.

If basesink was behaving as expected I would assume that these two pipelines
would produce very different results, but as a matter of fact, one works
perfectly, while the other is total crap:
gst-launch audiotestsrc ! dummyfilter drift=0 jitter=39999 ! pulsesink
gst-launch audiotestsrc ! dummyfilter drift=0 jitter=40000 ! pulsesink

And as I mentioned, my patch makes even extreme cases work (100ms jitter, 100us
drift-tolerance):
gst-launch audiotestsrc ! dummyfilter drift=0 jitter=100000 ! pulsesink
drift-tolerance=100

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