[MPlayer-dev-eng] [PATCH] mencoder: correctly consider encoder delays when examining muxer time

[Corey Hickey]

Hi,

mencoder currently takes into account encoder delays (how many frames
are stored in the encoder before being sent to the muxer) when
calculating A-V sync, but not when deciding whether to demux and encode
a video frame or an audio frame. If the second pass of a two-pass encode
has a different encoder delay, this can cause video and audio frames to
be handled in a different sequence.

Consider x264, which, with default options, has a 40-frame delay on the
first pass and a 3-frame delay on the second pass. During the beginning
of the first pass, mencoder will keep demuxing and encoding video frames
until the encoder delay is surpassed and mux_v->timer starts increasing;
only then will mencoder begin handling audio again.

This can cause a problem in some videos when mencoder decides to
skip/duplicate different frames; the second pass might have more frames
than the first, causing x264 to print this error and then segfault:

x264 [error]: 2nd pass has more frames than 1st pass (62011)
x264 [error]: continuing anyway, at constant QP=24
x264 [error]: disabling adaptive B-frames

I also imagine that having the video stream be offset by one or more
frames on the second pass will cause incorrect I-frame placement and
other ratecontrol problems, but I haven't verified this.

The attached patch adds a simple function for calculating
delay-compensated muxer timers, and then replaces all relevant instances
of mux_v->timer within mencoder.c. The patched mencoder correctly
handles my test file that caused a segfault before.

Does this look ok?

Thanks,
Corey
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: encoder_delay.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20101014/eea535f4/attachment.asc>