[x264-devel] [PATCH] Fix bug in fps/timestamp handling with lavf input

[Yasuhiro Ikeda]

For example, this source(which I posted to #x264 before).
http://www.mediafire.com/?ge7v1sde3gv77zr

Despite some warnings <http://www.privatepaste.com/76300990c3>, output had
seemed good till r1671. The warnings disappeared after the
video filtering system, but output got broken(as if it's 24000fps!) instead.
Ffmpeg+libx264, based
on same revision, still makes proper outputs. Lavf input must be fixed, not
ffmpeg/lavf itself.

Then I looked into the code and found pts is strange in some cases. Compared
with ffplay's code,
pts seems to get assigned improperly from frame.reordered_opaque even if
there's no reordering.

The non-strictly-monotonic pts warnings get resolved at
fix_vfr_pts.c(ll.100-101), but h->holder.pts
and h->buffer.pts are not assigned properly in the first place, so
h->last_duration is also irrelevant.

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


Yasuhiro Ikeda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20100805/cf7c826c/attachment.htm>