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