GNOME Bugzilla – Bug 696818
rtsprange: use gst_util_gdouble_to_guint64 in get_seconds
Last modified: 2013-04-02 20:27:26 UTC
Created attachment 240088 [details] [review] Use gst_util_gdouble_to_guint64 in get_seconds On our 32-bit machines, we get the following unit test error in the libs/rtsp suite (gst-plugins-base): gst-plugins-base/tests/check/libs/rtsp.c:525:F:general:test_rtsp_range_convert:0: 'str' (clock=20001010T120023Z-20320518T152245.119999885Z) is not equal to '"clock=20001010T120023Z-20320518T152245.12Z"' (clock=20001010T120023Z-20320518T152245.12Z) FAIL: libs/rtsp The error comes in the part of test_rtsp_range_convert with ranges that end in the year 2032, where we have large 64-bit numbers in the calculations. It turned out that the difference between actual and expected numbers occurs in the function get_seconds in gstrtsprange.c, where t->seconds * GST_SECOND is returned. That gdouble value is implicitly cast to a guint64 (GstClockTime) when returning from the function. On our 32-bit machines, the gdouble value 4177495365120000000.000000 becomes 4177495365119999885 in the cast. With the attached patch, which uses gst_util_gdouble_to_guint64 for the conversion, the test passes.
Shouldn't it be gst_util_gdouble_to_guint64 (t->seconds) * GST_SECOND to make sure we don't lose precision ?
No, then we would lose the fractional part of t->seconds. In this particular case t->seconds has the gdouble value 4177495365.12 before multiplying with GST_SECOND.
You're obviously right, I'm not sure what I was thinking. Committed commit 5ef9921bcd96c41bb7f55334625a7dd97dab67b5 Author: David Svensson Fors <davidsf@axis.com> Date: Thu Mar 28 23:02:11 2013 +0100 rtsprange: use gst_util_gdouble_to_guint64 in get_seconds https://bugzilla.gnome.org/show_bug.cgi?id=696818