On Wed, 05 Nov 2008 08:06:06 -0500, slippyr4 <[EMAIL PROTECTED]> wrote: > After the seek, I enter a decode loop. I dump the pts and dts from the > packet, and they come out as follows:- > > pts: -9223372036854775808 dts: 15027919 > pts: 15044400 dts: 15044400 > pts: 15058800 dts: 15048000 > pts: 15051600 dts: 15051600 > pts: 15055200 dts: 15055200 > pts: 15069600 dts: 15058800 > pts: 15062400 dts: 15062400 > pts: 15066000 dts: 15066000 > pts: 15080400 dts: 15069600 > pts: 15073200 dts: 15073200 > pts: 15076800 dts: 15076800 > pts: 15091200 dts: 15080400 decoded (this is the first packet which > avcodec_decode_video indicated was frame finished) > > Note that it's the 12th packet which resulted in the first "frame > finished", > and that frame's PTS is 15091200, which is 17 frames later than the > frame I > required.
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. -Mike _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
