GNOME Bugzilla – Bug 753881
hls/m3u8: make check fails for hlsdemux_m3u8 due to floating point rounding error
Last modified: 2015-08-28 18:28:08 UTC
The test_playlist_with_doubles_duration() test fails on some platforms due to rounding errors that occur when m3u8.c converts from the floating point value in the HLS manifest to a GstClockTime. make check failing for gst-plugins-bad has finally annoyed me enough times to actually have a go at fixing the problem!
Created attachment 309726 [details] [review] check: hlsdemux: make duration unit test robust to floating point rounding Using assert_equals_float() fixes the check failing because it handles the rounding error issues by accepting almost equal.
commit 48fefd8c841c6b22a620d3b6d6af5d062886627f Author: Alex Ashley <bugzilla@ashley-family.net> Date: Thu Aug 20 15:00:02 2015 +0100 check: hlsdemux: make duration unit test robust to floating point rounding The test_playlist_with_doubles_duration() test fails on some platforms due to rounding errors that occur when m3u8.c converts from the floating point value in the HLS manifest to a GstClockTime. Using assert_equals_float() fixes this because this function handles the rounding error issues by accepting almost equal. https://bugzilla.gnome.org/show_bug.cgi?id=753881
Same as bug #751766 fwiw.
*** Bug 751766 has been marked as a duplicate of this bug. ***
This patch does fix the test failure. But this fix seems to be more of a cover up of the issue right? I mean the actual code still has rounding errors and applications which try to use this will still face the issue. Though it is not a major issue to worry about i guess :)... But as i mentioned in the other bug, this seems to be more of a glib issue(g_ascii_strtod) The rounding off also seems to be random(maybe some specific, but could not deduce). For some values it works fine and for some it does not.