For example, this source(which I posted to #x264 before).<br><a href="http://www.mediafire.com/?ge7v1sde3gv77zr" target="_blank">http://www.mediafire.com/?ge7v1sde3gv77zr</a><br><br>Despite some <a href="http://www.privatepaste.com/76300990c3" target="_blank">warnings</a>, output had seemed good till r1671. The warnings disappeared after the<br>
video filtering system, but output got broken(as if it&#39;s 24000fps!) instead. Ffmpeg+libx264, based<br>on same revision, still makes proper outputs. Lavf input must be fixed, not ffmpeg/lavf itself.<br><br>Then I looked into the code and found pts is strange in some cases. Compared with ffplay&#39;s code,<br>
pts seems to get assigned improperly from frame.reordered_opaque even if there&#39;s no reordering.<br><br>The non-strictly-monotonic pts warnings get resolved at fix_vfr_pts.c(ll.100-101), but h-&gt;holder.pts<br>and h-&gt;buffer.pts are not assigned properly in the first place, so h-&gt;last_duration is also irrelevant.<br>


<br>My first patch changes not to use frame.reordered_opaque if it seems wrong according to<br>c-&gt;has_b_frames. This should make h-&gt;holder.pts, h-&gt;buffer.pts, and h-&gt;last_duration sane, so<br>resulting fps/timestamp as well. After some sort of testing, with Bframes and no-Bframes, CFR <br>
and VFR, and various file types(mov, mp4, y4m, mkv, and avi), etc... this seems fine.<br><br><br>Yasuhiro Ikeda<br>