[MPlayer-users] RFC: docs update for "how to create a high quality DVD rip"

[Hans du Plooy]

On Monday 07 June 2004 06:05, D Richard Felker III wrote:
> > known.  Given that, I don't see why filters that add/drop frames don't
> > work with 3-pass.
> >
> > Require enlightenment ...
>
> Nope, the first (frameno) pass does the a/v sync (choosing which
> frames to drop or duplicate) which can't be done correctly without
> decoding and filtering them. And it doesn't decode them. So it's
> broken.

Either of us are misinterpreting the way 3-pass works.  This is my take:

In 3-pass mode, the first pass only decodes the audio and encodes it into 
whatever you want.  It does not decode the video at all (else it would be a 
lot slower than it is).  It probably only looks at the size of the video and 
gives you a rough estimate of what bitrate you should use to get the desired 
size.  That estimate is not 100% correct, but mostly quite accurate.  If you 
do a 1st pass (of 3), and do it again, but crop a healthy chunk of the movie 
away, you'll see the estimated video bitrate doesn't differ much (if at all).  
So I think it's safe to say the first pass doesn't care about the video, so 
it doesn't do a/v sync at all.

In 3-pass, the second pass decodes the video, calculates the best way to 
decode each frame, and logs it (notice that the divx2pass.log only appears 
when you do the second of three passes, not during the first).  Now the audio 
is already in its final form, so it has all it needs to work out the a/v 
sync.

In 3-pass mode, the third pass looks at divx2pass.log and encodes the video 
accordingly.

the a/v sync trouble you have has nothing to do with 3-pass mode.   I'll tell 
you what does screw you around on a/v sync though:  encoding your audio in 
vbr with lame (not sure about ogg or other formats).  It has for a long time 
bugged me that my DVD rips come out with audio all over the place.  
Strangely,  this symptom was worst in MPlayer, which I found strange, having 
encoded the movies with mencoder.   Eventually I found out that vbr audio 
causes a/v sync problems, 2-pass or 3-pass all the same.  This was two or so 
years ago though, it might have been fixed in the meantime.

Hans

>
> If you want to do the same sort of thing correctly, you should encode
> the audio separately with lame, then mux it with -oac copy and
> -audiofile during the normal 2 passes. This is actually the best way
> since bugs in mencoder cause slight a/v desync with modern versions of
> lame due to lack of buffer measurement.
>
> > > Um, let's see. 900/96 video/audio bitrate, or 804/192? I'll take the
> > > former any day! It's an absolutely HUGE difference! For me. I
> >
> > A good part of the movie experience for me is the sound.  I put a lot of
> > money into my home theatre setup, and when I hear crap in my rear
> > speakers because my receiver is trying to find a channel in the high
> > frequencies that has been compressed to hell, I go batty.  It's really
> > annoying. :)
>
> Then disable that "feature"...
>
> > > Otherwise (whenever you have a size constraint, no matter how big)
> > > most of your recommendations are the exact opposite of what helps, and
> > > stupid users will try them anyway...
> >
> > I wonder if "most" is true.  Out of all the points in that text, I think
> > the only ones that will hurt a size constraint is "don't scale" and
> > "don't transcode audio."
>
> Also: don't denoise.
>
> > Speaking of "don't scale," what's your opinion on cropping to multiples
> > of 16, or cropping to the exact rectangle and then scaling up to a
> > multiple of 16?
>
> Never scale up. Always scale down or not at all. Personally my pick
> depends on whether the original was a movie or made-for-tv. I always
> try to avoid vertical scaling when the original was made for tv (since
> the line sampling corresponds to the way the content was originally
> recorded) but that's pretty irrelevant when the original is film.
>
> > > And several hundred more gigs for backups? :) Storing your only copies
> > > on hd is not very smart...
> >
> > They're not my only copies.  I have perfectly good backups sitting on a
> > shelf in the other room: the actual DVDs. :)
>
> And it takes months to restore them (reencode).
>
> > > I _know_ you'll see them if you leave black borders, but insane
> > > bitrate might mostly compensate, as least with qmin=1. With unaligned
> > > dimensions I haven't tested, but in theory it should have a similar
> > > effect.
> >
> > I guess that makes sense.  Lower bitrates means you have a lot less room
> > for mistakes in cropping, scaling, etc.
>
> Yes, or conversely using insane bitrates lets you get by with being
> sloppy. And I don't like sloppiness.
>
> Rich
>
> _______________________________________________
> MPlayer-users mailing list
> MPlayer-users at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-users