[MPlayer-users] Re: Documentation update.

[D Richard Felker III]

On Sat, Sep 13, 2003 at 07:56:02AM -0500, Jonathan Rogers wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Matthias Wieser wrote:
> >Which bugs? In the documentation I could not find a reason not to use 
> >3-pass encoding. With google I found: 
> >http://mplayerhq.hu/pipermail/mplayer-users/2003-May/033019.html
> 
> The main reason not to use 3-pass is that it's a waste of time, 
> especially if you're going to end up with an OGM. It doesn't do anything 
> that 2-pass doesn't. Maybe I'm missing something, but I've never 
> understood its purpose. I tried it a few times because it was 
> recommended, but the end result was indistinguishable from using 2-pass.

The only purpose is for encoding mp3 with lame. In the first pass
("pass 0") you encode the audio with vbr, and you get the exact audio
bitrate. Then you can tune the video bitrate for pass 1 and 2 so that
it exactly fills the CD, maximizing quality. With OGM, you do the same
thing by encoding your vorbis audio in a .ogg file before you even
begin video encoding.

The problem with the 3pass code, though, is that it doesn't just
encode the audio. It also makes a table of input/output frame
correspondence for A/V sync, but without decoding any video, just
using info from the demuxer. This will work under ideal conditions,
but if any frames get dropped by the decoder (e.g. they're damaged
beyond recovery) or by the vf chain during pass 1/2, the sync
info from pass0 will be bogus and will result in a bad output file.

There are two possible fixes:

1) Don't include frame numbers in frameno.avi, just timestamps. Then
   sync video to these timestamps during pass 1/2.

2) Get rid of pass0 and merge it with pass1. I.e. generate frameno.avi
   at the same time the first video pass is being performed, then copy
   audio from it during the second video pass.

Rich