[gstreamer-bugs] [Bug 636037] audiotestsrc timestamps are imprecise in general

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #3 from Jordi Burguet-Castell <jordi.burguet.castell at gmail.com> 2010-12-01 22:50:53 UTC ---
Hello David,

I'm worried about that. With a truncation a timestamp of 99.9999 is 99 instead
of 100. If you round you can be off by half a nanosecond, yes, but you have the
closest representation of the real time. I don't see it as a matter of "only
having an error twice as big", but of what is the proper representation. That's
what you also get with floating-point operations.

More worrying for data analysis, when you accumulate a series of timestamps
that are computed by truncation, you accumulate an error of half-nanosecond per
buffer, on average. And it only keeps growing. (This doesn't really apply to
this element, but it's true in general.) With rounding that doesn't happen, the
errors cancel out.

As for the case of half-nanoseconds, which as far as I know is the only
possible complication, what is done in using gst_util_uint64_scale_round() [1]
can (and probably should) be used as reference, and it is actually one of the
standard ways to do it in floating point arithmetic [2].


[1]
Basically, create a half-open interval [-0.5,+0.5) centered in each nanosecond:
http://en.wikipedia.org/wiki/Rounding#Round_half_away_from_zero

[2]
http://en.wikipedia.org/wiki/IEEE_754-2008

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