[MPlayer-dev-eng] a/v sync and encoding with lame vbr

[D Richard Felker III]

A thread keeps popping up again and again on -users about a/v desync
problems when encoding audio with lame in vbr mode. I've never noticed
this myself, but several users report that it's quite bad, and since
I'm working mostly with anime (in which desync isn't as noticable),
it's possible that there really is a bug.

Anyway, a few days ago I noticed a possible symptom while encoding. I
was doing 2pass encode, with -oac copy on the first pass, and -oac
mp3lame on the second. With -oac copy, there were no duplicate frames
or skipped frames, and a/v sync was perfect. With -oac mp3lame in vbr
mode, there was a skipped frame within the first second of encoding.
The problem went away by switching to cbr, but in the end I just used
-mc 0 -noskip so I could do vbr.

It's been mentioned that such a bug might be related to lame buffering
up more audio when in vbr mode, so I'm trying to look into the
possibility. However, the code in mencoder.c looks like nonsense.
Could someone who understands it (Arpi, did you write this?) take a
look around lines 960-1008 of mencoder.c, and explain what it's
supposed to do? The second while loop (while(mux_a->buffer_len<len))
particularly makes no sense; the way it's used, it can only be
executed once or not at all, so from a readability standpoint it
should be if and not while. Unless the code is buggy. Which may be
likely since it looks so nonsensical... I assume it wants to encode
exactly one mp3 frame, but I'm not sure how it intends to accomplish
that...


Rich