Gregory Maxwell wrote:
I don't see how you can fix it in normalizeParams call unless you've scanned the stream and know where the keyframes are.
Well, we do actually scan the stream. We interpret the granule position of each page and record the last granule position in the stream for the purposes of calculating stream length. It would be easy enough to make a note of the last keyframe position as well.
But when I said a one-line fix, I was thinking along the lines of a fixed heuristic distance between keyframes, either in time or frame count, that roughly matches the characteristics of common encoders. If the requested seek time is too close to the end, it would be moved back, possibly right back to the start. This is already implemented, but there's a bug in it for short streams which may be causing trouble. Or the period may not be long enough.
Obviously if there is some encoder that, with the default settings, is generating 10 second files with a single keyframe and 240 inter frames, and this encoder is significant for Wikimedia, then I will have to rethink this approach.
-- Tim Starling