On Thu, Jul 19, 2012 at 12:42 PM, Carl Eugen Hoyos <[email protected]> wrote: > [...] > Afair, Reimar believes the seek function should not try hard to find > a keyframe because seeking faster is more important.
I think the current functionality is OK, provided it's documented well. Though to be honest I'd like an a flag/function that provided additional seeking ability, but like Hendrik said that's been an unfinished GSOC project for awhile so I'm not expecting it anytime soon. > I honestly cannot comment on the flags-value, I can only confirm > that FFmpeg only seeks to keyframes for your sample here. What's the expected behavior of avcodec_decode_video2() and seeking? I understand that things like P and B frames require lavc to do some frame buffering, but if ffmpeg seeks to a keyframe, can I expect the first call to avcodec_decode_video2() to return a fully decoded frame? (and then after that possibly make several calls before getting a full frame out if there are P or B frames after this keyframe) The first 54 packets out of av_read_frame() have .flags=0 (checked with -dump and -loglevel debug). Could they be wrong if ffmpeg is indeed seeking to a keyframe? Visually, things look ok (aside from the frame being ~1.5 seconds after the requested time), but I think that's because ffmpeg just keeps reading and decoding until it gets a full frame out, and it won't do that until it hits a keyframe, and that it's disguising the fact that it's not seeking to a keyframe (or maybe that a packet's .flags value is lying). But I could be misunderstanding something. Thanks, Michael _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
