Hendrik Leppkes <h.leppkes@...> writes: > On Thu, Jul 19, 2012 at 8:31 AM, Carl Eugen Hoyos wrote: > Isn't this necessary for some codecs / at least for H264? > Wouldn't the API do exactly the same? > > Sure, if you end up seeking to a non-keyframe, it should not > decode garbage frames.
> The point here is that we would want to > actually end up on a proper keyframe. I thought that valid H264 streams do not necessarily contain key-frames. (FFmpeg is supposed to seek correctly in such files.) > > But the idea is to ensure that you can decode as of time X, > > which means you need to seek to the last keyframe *before* > > time X, which is something that is not supported currently. > I see. > (But am I wrong to assume that this is not generally possible, > assuming large GOPs?) > > Even a large GOP has a start somewhere. Granted seeking might > take a bit longer because reading data backwards to find the > keyframe is not as ideal as going forward, but it should be > possible. So if the file is ~2GB and (as a user) I seek approximately to the middle of the video and decide to seek back then, the video should be decoded from the beginning to find the keyframe before the position I want to seek to? (I am just trying to find out if I am correct in my believe that it is not generally possible / useful to seek to the latest keyframe before the requested position, but that the only realistic approach is to seek to the nearest keyframe at or later than requested.) Carl Eugen _______________________________________________ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user