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'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's code,<br>
pts seems to get assigned improperly from frame.reordered_opaque even if there's no reordering.<br><br>The non-strictly-monotonic pts warnings get resolved at fix_vfr_pts.c(ll.100-101), but h->holder.pts<br>and h->buffer.pts are not assigned properly in the first place, so h->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->has_b_frames. This should make h->holder.pts, h->buffer.pts, and h->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>