On Wed, Jan 28, 2015 at 2:59 PM, Carl Eugen Hoyos <[email protected]> wrote:
> Max Vlasov <max.vlasov@...> writes: > > > The idea was to read all packets saving pts and > > keyframe flag (without decoding) and make a list > > of them in order of ptses. > > (What are "packets" for you?) > > I don't know your exact requirements but at least > for H.264 this approach cannot work. > > I used av_read_frame reading packets from the video stream until the end of file and stored pts of this structures reordering them assuming one packet = one frame. If pts is AV_NOPTS_VALUE (non-keyframe in avis) then I assumed the sequential order relative to the previous one. I tested thie algorithm determining the correct frame number by sequential decoding and after that trying to jump to the same frame number with this algorithm with a freshly opened file. Several files I tried (mp4, wmv, avi, mkv (h264 inside)) worked ok. Apart from the one I mentioned (with dozens of small packets), the heaviest deviation was for a ts file recorded by a hdtv player from the air. Another one has exactly one frame difference for the whole file So if there's a legitimate reason why a packet that is a part of a video stream may appear, but not used as a frame then it's ok I missed something. I just would like to know what exactly I missed :)
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
