<div dir="ltr"><br><div><div><div><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 28, 2015 at 2:59 PM, Carl Eugen Hoyos <span dir="ltr"><<a href="mailto:cehoyos@ag.or.at" target="_blank">cehoyos@ag.or.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">Max Vlasov <max.vlasov@...> writes:<br>
<br>
> The idea was to read all packets saving pts and<br>
> keyframe flag (without decoding) and make a list<br>
> of them in order of ptses.<br>
<br>
</span>(What are "packets" for you?)<br>
<br>
I don't know your exact requirements but at least<br>
for H.264 this approach cannot work.<br>
<br></blockquote></div><br><div><div>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. <br>If pts is AV_NOPTS_VALUE (non-keyframe in avis) then I assumed the sequential order relative to the previous one. <br>   <br></div><div>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. <br></div>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 <br></div>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 :)<br><br></div></div></div></div></div>