GNOME Bugzilla – Bug 636037
audiotestsrc timestamps are imprecise in general
Last modified: 2010-12-02 07:01:54 UTC
Created attachment 175448 [details] [review] use gst_util_uint64_scale_int_round() to compute timestamps The audiotestsrc element sets and reports the timestamps of the buffers it creates with a small error. Basically, by using gst_util_uint64_scale_int() in some places, the timestamp can be off by almost a nanosecond. In our pipeline we are sensitive to any error in the timestamp, and because of this (small) problem we can't use audiotestsrc to test it. Fortunately, the fix is very easy. In audiotestsrc the timestamp (in "next_time") is computed always from next_sample, so it can be solved by changing gst_util_uint64_scale_int() to gst_util_uint64_scale_int_round() (note the extra "_round") everywhere. Patch attached.
Just to be more clear: An example where one sees the problem, at rate=44100Hz if you start at t=0, after 1 sample you will be at t = 1/rate = 22675.74 ns. If you get it with gst_util_uint64_scale_int(), that's a 22675. But with gst_util_uint64_scale_int_round() you get 22676, which is arguably the best one. As for the patch, it works because in audiotestsrc the timestamps are always computed from the "bytestamps", that is, how many bytes away we are from timestamp=0 (stored in a variable called "next_sample"). Finally, I've run the unit tests ("make check" in gst-plugins-base) and they all passed with no error.
GStreamer is pretty consistent about using gst_util_uint64_scale() to generate timestamps. It was defined to that way (truncation of any fractional nanoseconds), since it is simple, and any other system (i.e., rounding) is significantly more complex to test and get right (rounding of half-nanoseconds, for example). As a side note, using rounding instead of truncation merely offsets timestamps by a half a nanosecond.
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
The value of absolute timestamps are never useful by themselves. They're only useful when compared to another timestamp in the same timebase. When you look at timestamp differences, the sub-nanosecond residuals are centered around zero, and range from -1 to +1, just as with every other difference measurement system.