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 727863 - gst_query_parse_buffering_range always returns -1 on Windows
gst_query_parse_buffering_range always returns -1 on Windows
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other Windows
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-04-08 20:33 UTC by Alex Christensen
Modified: 2017-07-14 15:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test file (3.78 KB, text/plain)
2014-04-08 22:44 UTC, Alex Christensen
Details

Description Alex Christensen 2014-04-08 20:33:40 UTC
I've been trying to debug the GStreamer-based HTML5 video player in the WinCairo port of WebKit on Windows for a while with no success.  gst_query_parse_buffering_range is used to see how much of the video has downloaded, and it works on Linux with GStreamer 1.2.1 but not on Windows with GStreamer 1.2.1 or 1.2.3.  I made a small test application using http://media.w3.org/2010/05/sintel/trailer.ogv as the URI and basically calling gst_element_factory_make("playbin", "play") and gst_query_parse_buffering_range on a query to it from gst_query_new_buffering.  The video plays fine and buffers fine, but I do not get the needed information about the buffering.  I'm not sure where more to look, and I can't figure out how to build GStreamer for windows to debug my own builds.

I commented out the gst_element_register calls in http://trac.webkit.org/browser/trunk/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp and the problem arises in MediaPlayerPrivateGStreamer::fillTimerFired
Comment 1 Tim-Philipp Müller 2014-04-08 21:05:58 UTC
I am not sure if download buffering will be used for .ogv in 1.2.x, there used to be a whitelist of formats at some point. Try an .mp4 file instead.
Comment 2 Alex Christensen 2014-04-08 22:30:04 UTC
The same problem exists with http://media.w3.org/2010/05/sintel/trailer.mp4

Should I post my test case?
Comment 3 Alex Christensen 2014-04-08 22:44:17 UTC
Created attachment 273840 [details]
test file

This file prints start and stop values, which are always -1 (represented as a large unsigned 64-bit integer) on Windows
Comment 4 Sebastian Dröge (slomo) 2014-04-09 07:07:57 UTC
You mean it always return -1 as start and stop? The other values returned by gst_query_parse_buffering_range() are provided properly here, but those two are always -1. Is that what you mean?



For testing with git master, it's even more broken there because of bug #727821 right now.
Comment 5 Alex Christensen 2014-04-09 15:01:21 UTC
format is the same value I give to gst_query_new_buffering
start is always -1
stop is always -1
estimated_total is always -1

I'm especially confused why gst_query_parse_buffering_percent gives me useful values relative to the current buffer, but gst_query_parse_buffering_range does not.
Comment 6 Tim-Philipp Müller 2017-07-14 15:16:31 UTC
Not sure what to do about this, but I don't think it makes sense to keep this open. Please feel free to re-open if it's still a problem and we can somehow reproduce it.