After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 751766 - m3u8: test_playlist_with_doubles_duration failure
m3u8: test_playlist_with_doubles_duration failure
Status: RESOLVED DUPLICATE of bug 753881
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-07-01 03:55 UTC by Vineeth
Modified: 2015-08-20 14:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to fix test failure (909 bytes, patch)
2015-07-01 03:58 UTC, Vineeth
none Details | Review

Description Vineeth 2015-07-01 03:55:51 UTC
test_playlist_with_doubles_duration test of hlsdemux_m3u8 fails because,
when a string is converted to double using g_ascii_strtod and the same value is
then converted to GstClockTime, for some values of float, the conversion is not happening properly

The failure is as below.
elements/hlsdemux_m3u8.c:561:F:m3u8client:test_playlist_with_doubles_duration:0: 'file->duration' (10320999999) is not equal to '10.321 * (1000000 * (__extension__ (1000LL)))' (10321000000)

Let us take the example of 10.321 float value, given in DOUBLES_PLAYLIST of hlsdemux_m3u. This when got using g_ascii_strtod and then multiplying by GST_SECOND,
instead of giving 10321000000, the value is coming as 10320999999
For 10.322 also there is error in calculations.
for 10.323, the value is coming properly as 10323000000. For 10.320 also it is proper.

Similarly for 9.92, there is error, along with 9.93, 9.94, 9.95 are giving errors, but 9.90, 9.91, 9.96, 9.97 are giving proper values

Not sure what exactly is happening and how does the calculations vary based on different values.
But if i change the duration variable to gdouble, then there is no error.
And while passing the duration value to gst_m3u8_media_file_new, which expects GstClockTime duration, then it gets converted properly and all the calculations are happening properly without any failures.
Comment 1 Vineeth 2015-07-01 03:58:03 UTC
Created attachment 306467 [details] [review]
patch to fix test failure

Not exactly sure if this is a valid patch. But with this all calculations of duration seems to be proper and all the tests pass.
i guess there might be a better solution for this.
Comment 2 Luis de Bethencourt 2015-07-01 17:03:56 UTC
Could you investigate this further to understand why the original code fails and the patch works? Only knowing this will we know if the patch is the most appropriate solution.
Comment 3 Vineeth 2015-07-15 03:23:07 UTC
Noticed something weird..
The test works fine in one system, but not in another. Both are tested with latest master branch.
Thought there might be some difference in libc versions of both the systems, but even those are same.
This might actually not be an issue with Gstreamer as such.
So not sure if this is needed. 
Couldn't find out what might cause this(maybe some difference in g_ascii_strtod).. 
So maybe we can just resolve as not going to fix, since it is not related to Gstreamer..
Comment 4 Vineeth 2015-08-06 04:52:31 UTC
Resolving as obsolete because, this doesnt seem to be related to Gstreamer. It fails only in this particular PC. It does not fail in any other system with the same Gstreamer version.
Comment 5 Sebastian Dröge (slomo) 2015-08-20 14:23:06 UTC

*** This bug has been marked as a duplicate of bug 753881 ***