[Ffmpeg-devel] [PATCH] Ratecontrol 2nd pass bug

[Rich Felker]

On Thu, Sep 08, 2005 at 01:19:54AM +0930, Mark Williams (MWP) wrote:
> > On Wed, Sep 07, 2005 at 06:01:29PM +0930, Mark Williams (MWP) wrote:
> > > Greetings all,
> > > 
> > > My first patch submission, so be nice :)
> > > 
> > > This stops the assertion that occours if the 2nd pass encoding has more frames
> > > than in the 1st pass log.
> > > 
> > > I have this problem frequently when encoding TS/TP files.
> > 
> > Because your mencoder command lines are wrong but you didn't tell us
> > them for us to check..
> 
> Ok, rather than polute ffmpeg-dev...

...you decide to pollute my personal mailbox instead. Gee, thanks.
Please don't take discussions off list, as they're informative to
other people too. That's why we have a list rather than a private q&a
hotline. :)

> Whats wrong with:
> 
> mencoder -o video-first.avi -sws $SWS \
> 	-oac mp3lame -lameopts mode=1:cbr:br=32:aq=8 \
                               *********************
> 	-ovc lavc -lavcopts $LAVC:vbitrate=$BITRATE:vpass=1:turbo \
> 	-vf $VF $FILES
> 
> mencoder -o video-final.avi -sws $SWS \
> 	-oac mp3lame -lameopts $LAMEOPTS \
                               *********
> 	-ovc lavc -lavcopts $LAVC:vbitrate=$BITRATE:vpass=2:psnr \
> 	-vf $VF $FILES

See above? Not the same. Lame's buffering is different with cbr versus
vbr, which means mencoder's buggy a/v sync will be different, which
means 2pass video will not work correctly.

If -mc 0 works with your content, this will get around the problem.
Otherwise you must use identical audio options for both passes (well
not quite identical but I'll leave it to you to figure out which ones
are safe to change. Probably aq is safe, but not others.

Rich