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