I would like to locate key frames to enable faster seeking when a video
has widely spaced key frames. For example if the place we want to seek
to is just before a key frame then the seek will be very slow (I've seen
up to 3 seconds), but if we know where the key frames are, then it might
well be acceptable to seek instead to the key frame just after the
I have written a "pre-scan" technique which locates all key frames in
advance. It works by seeking to the next key frame (flags
GST_SEEK_FLAG_KEY_UNIT | GST_SEEK_FLAG_SNAP_AFTER), get the location,
add a little, then seek from there to the next key frame, etc. But this
can take 10 or 20 seconds on large videos. So my first question is, is
there a faster way of doing such a pre-scan?
Failing that, I'm thinking of collecting key frame positions
incrementally while we play, using a pad probe. I tried placing a pad
probe after decodebin but I find *none* of the buffers have
GST_BUFFER_FLAG_DELTA_UNIT, so they all appear to be key frames, which
is wrong of course. According to this very old post:
"- decodebin outputs decoded raw video frames; I don't think the
semantics of keyframe/not-keyframe are very well defined for raw video
frames. I would not rely on decoders flagging their output buffers
consistently one way or another or at all
- you are likely to get better results if you check for keyframes on
buffers before they go into the decoder"
But how can I do that? Do I need to investigate the internals of how
decodebin works? Any advice would be welcome.