[Bug 781776] decklink: Detect gaps on incoming stream times, issue warnings

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=781776

--- Comment #17 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Vivia Nikolaidou from comment #16)
> (In reply to Sebastian Dröge (slomo) from comment #14)
> > Review of attachment 353815 [details] [review] [review]:
> > 
> > ::: sys/decklink/gstdecklinkaudiosrc.cpp
> > @@ +690,3 @@
> > +    if (self->expected_stream_time != GST_CLOCK_TIME_NONE &&
> > +        ABSDIFF (self->expected_stream_time, p.stream_timestamp) >
> > +        gst_util_uint64_scale (2, GST_SECOND, self->info.rate)) {
> > 
> > 2 samples? Why not > 1?
> 
> Remember those jittery 29.97 audio timestamps? :)

Makes sense, can you add a comment about that? With drop-frame we have gaps of
1 sample every now and then (rounding errors because of the samples-per-frame
pattern which is not 100% accurate), and due to rounding errors in the
calculations these can be 2>x>1.

> > @@ +805,3 @@
> > +  self->processed += f.stream_duration;
> > +  if (self->expected_stream_time != GST_CLOCK_TIME_NONE &&
> > +      ABSDIFF (self->expected_stream_time, f.stream_timestamp) > 1) {
> > 
> > 1ns seems dangerous, are you sure? There might be rounding errors with the
> > duration.
> > 
> > Maybe > 1/fps?
> 
> It's >1, so any rounding error would make it == 1, so the if wouldn't be
> activated. :) From what I've seen, this works well enough already.

Ok, also add a comment about that please

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.