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 685818 - Queue2 doesn't change fill level when seeking back into a "hole"
Queue2 doesn't change fill level when seeking back into a "hole"
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 635637
 
 
Reported: 2012-10-09 16:42 UTC by Bastien Nocera
Modified: 2018-11-03 12:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Bastien Nocera 2012-10-09 16:42:04 UTC 
See bug 635637 for Totem's implementation.

When download buffering, we should be able to skip forward past the fill level (which seems to work) but when seeking back into a "hole", we should be resetting the fill level to match the current location of the slider.

Eg:
1. launch totem test suite (in browser-plugin/tests/, run launch-web-server.sh start)
2. link a file that can be "download-buffered" in browser-plugin/tests (ln -s /test-file/blah.mov foo.mov)
3. play the movie: totem http://localhost:12345/foo.mov
4. click far forward (buffer level moves with it)
5. click back quite a bit again (buffer level doesn't move back, even though this section of the video isn't download)

You'll also notice that the fill level doesn't seem to match the slider's position, which is a bit of a problem...
Comment 1 Bastien Nocera 2013-08-23 17:46:37 UTC 
This is still a problem. Is it possible to get arbitrary seeking working when download-buffering with GStreamer right now? In which case, some example code would be appreciated so I can fix Totem's implementation.
Comment 2 GStreamer system administrator 2018-11-03 12:16:18 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/31.