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 752374 - dashdemux: gst_dash_demux_get_live_seek_range should not return negative values
dashdemux: gst_dash_demux_get_live_seek_range should not return negative values
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.7.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-07-14 14:24 UTC by Florin Apostol
Modified: 2016-02-10 22:27 UTC
See Also:
GNOME target: ---
GNOME version: ---

proposed patch (2.66 KB, patch)
2015-11-20 19:39 UTC, Florin Apostol
committed Details | Review

Description Florin Apostol 2015-07-14 14:24:54 UTC
If availabilityStartTime is larger than current time (stream not yet available), the gst_dash_demux_get_live_seek_range function will set negative values in start and stop parameters and return TRUE.

It is not very sure if the caller will validate the fact that start and stop are positive numbers. I believe the function should return FALSE if availabilityStartTime is bigger than current time and start and stop would be negative.
Comment 1 A Ashley 2015-07-15 11:43:46 UTC
I'm not sure about that. I think gst_dash_demux_get_live_seek_range() function should only return FALSE if it fails to calculate the range. The fact that the range is empty is not an error in the gst_dash_demux_get_live_seek_range() function, it is simply that there is no available fragments.
Comment 2 Florin Apostol 2015-07-15 11:59:53 UTC
the range will contain negative values. For example start=-10 stop=-5. Is this a valid range? I think not. And I doubt that callers of this function will check that start and stop are >0. And if later start and stop are used in unsigned comparisons, we will have a big problem.

We could set start=0 and stop=0 if you want to return true. But I don't think it is normal to return true and set start=-10 stop=-5
Comment 3 Sebastian Dröge (slomo) 2015-11-16 12:57:26 UTC
Anything to be done here still?
Comment 4 Florin Apostol 2015-11-17 16:48:14 UTC
The main question is: is it allowed to have negative values in start and stop parameters for a seek range? For example, is start=-10 stop=-5 a valid range for seek? 
Negative values means the position will be before the stream is available. Usually seek range is between 0 and now - availabilityStartTime. Both of them are positive.
Comment 5 Sebastian Dröge (slomo) 2015-11-18 07:30:28 UTC
No, negative start/stop values are not supported for seek events.
Comment 6 Florin Apostol 2015-11-20 19:29:57 UTC
The function returns an incorrect start value if timeShiftBufferDepth is not defined (-1). The function returns as start the stop + 1ms, which is obviously wrong. In this case, according to the standard the buffer should be infinite so start should be 0.

I'll correct the function to return only positive values for start and stop.
Comment 7 Florin Apostol 2015-11-20 19:39:07 UTC
Created attachment 315989 [details] [review]
proposed patch
Comment 8 Thiago Sousa Santos 2016-02-10 22:26:33 UTC
Merged, did a little amend to consider the lack of availabilityStartTime a runtime error not an assertion as it is read from the input.

commit 88e21e6089bade0e2ddc5557c4ee41dce8b3ce24
Author: Florin Apostol <>
Date:   Fri Nov 20 19:38:03 2015 +0000

    dashdemux: gst_dash_demux_get_live_seek_range returns positive values