GNOME Bugzilla – Bug 619788
[API] seeking: need API to do pseudo-accurate seeking when keyframe seeking is too coarse
Last modified: 2018-11-03 12:14:06 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.
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.
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
(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
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.
*** Bug 624174 has been marked as a duplicate of this bug. ***
Moving to core, since this requires new API to tell the parser/demuxer about the max-keyunit-distance restriction.
-- 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.