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 619788 - [API] seeking: need API to do pseudo-accurate seeking when keyframe seeking is too coarse
[API] seeking: need API to do pseudo-accurate seeking when keyframe seeking i...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 624174 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-05-27 08:20 UTC by Benjamin Otte (Company)
Modified: 2018-11-03 12:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Benjamin Otte (Company) 2010-05-27 08:20:21 UTC
Totem currently does keyframe seeking of videos. However, videos exist that only contain a single keyframe at the beginning of the file. For these files, every seek will result in Totem restarting the file.
Comment 1 Tim-Philipp Müller 2010-05-27 08:43:03 UTC
Sure, these files exist, and we should handle this properly, but making totem default to accurate seeking is not a good solution at all.

Accurate seeking means: seek accurately no matter how long it takes or how expensive it is. For many types of files this may involve scanning from the start to the seek position, especially as we implement this more widely in future.

This does not seem a good idea just to handle a few broken files.

We should find a solution for this at the GStreamer level. One could add API to specify some type of 'max. keyframe snap distance' for keyframe seeks, or make demuxers automatically adjust the segment start position if the keyframe we found is too far away from the desired seek position (e.g. more than 3-5 seconds). Some demuxers already do this IIRC, and it would effectively be like an accurate seek, just without the expensive logic in the demuxer to ensure the seek position is really accurate.
Comment 2 Benjamin Otte (Company) 2010-05-27 11:41:40 UTC
I have no idea how much overhead it would be for an average file, so assumed it could be enabled unconditionally, which would be the easiest solution. Did anyone ever try that?

I suspect that for a user everything that counts is not seeing the slider jump too much when seeking. Also, when scrubbing through the file, accuracy of course is not that important as it is when trying to find a certain scene. So I suspect the accuracy of the seek should be influenced by the pixel size of the slider and the speed of it? I don't know.

Also, the test file I was talking about is at http://people.freedesktop.org/~company/stuff/batman-clippers.mov
Comment 3 Bastien Nocera 2010-05-27 12:20:32 UTC
(In reply to comment #2)
> I have no idea how much overhead it would be for an average file, so assumed it
> could be enabled unconditionally, which would be the easiest solution. Did
> anyone ever try that?

Given that seeking is already not fully async, I doubt that's going to make interactivity any better.

> I suspect that for a user everything that counts is not seeing the slider jump
> too much when seeking. Also, when scrubbing through the file, accuracy of
> course is not that important as it is when trying to find a certain scene. So I
> suspect the accuracy of the seek should be influenced by the pixel size of the
> slider and the speed of it? I don't know.

I'd like to see a new flag that would take into account the type of file, and the size of it when seeking, so that ACCURATE would be automatically used if the accuracy would be as dire as in the example file.

> Also, the test file I was talking about is at
> http://people.freedesktop.org/~company/stuff/batman-clippers.mov
Comment 4 Tim-Philipp Müller 2010-05-27 12:36:41 UTC
Just to be clear, we don't really want to do "accurate" seeking in those cases, more pseudo-accurate. We usually don't really care if the position seeked to is 100% correct or not (relative to start), we just want decent-enough seek/slider granularity.
Comment 5 Philip Withnall 2010-07-15 08:40:26 UTC
*** Bug 624174 has been marked as a duplicate of this bug. ***
Comment 6 Tim-Philipp Müller 2012-02-18 17:03:46 UTC
Moving to core, since this requires new API to tell the parser/demuxer about the max-keyunit-distance restriction.
Comment 7 GStreamer system administrator 2018-11-03 12:14:06 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/15.