GNOME Bugzilla – Bug 727863
gst_query_parse_buffering_range always returns -1 on Windows
Last modified: 2017-07-14 15:16:31 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
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.
The same problem exists with http://media.w3.org/2010/05/sintel/trailer.mp4 Should I post my test case?
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
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.
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.
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.