2008/11/5 Michael Conrad <[EMAIL PROTECTED]> > > Keep in mind what the FrameFinished flag means. The decoder is allowed to > hold onto any number of frames that it likes, so long as it returns them > to you in order. The packet you give to decode_video is unrelated to the > picture you get back from it. If you look at the source for ffplay.c, you > will see that there is a hack where the get_buffer and release_buffer > functions attach the current packet pts to the frame's opaque pointer. > They do this to keep track of which packet created an image. > > Having said that, it is generally agreed that seek is a bit... quirky. > There were some posts on this list about 2 months ago about a > frame-accurate-seek library which builds an index of how to reach each > frame. > > Thanks Mike.
I'm already using the get_buffer/release_buffer+opaque hack for pts, but obviously with those you only get a result in the event that framefinished == TRUE. That first decode that returned framefinished=TRUE had a pts way beyond what I was looking for. I don't mind seeking a little bit earlier than my target and doing some extra decodes, but what is still confusing me is that it's taking 17 frames before I get a valid frame back. Surely if the GOP size is 12, then at the very latest I should be able to get a frame for the 11th decode - ie. the first I-frame we come across? _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
