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
desired point.
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:
http://gstreamer-devel.966125.n4.nabble.com/keyframes-from-a-video-td973102.html"- 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.
Regards,
Andy Robinson, Seventh String Software, www.seventhstring.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Locked
