[MPlayer-users] MEncoder and MPlayer breaking a/v sync in certain MPEG4 avi files

[Mark Nagy]

   I know I already sent this, but it "silently failed", leaving me to 
wonder whether the fact that it didn't show up was a deliberate 
rejection or a technical problem.  So I'm trying it again without the 
"reply-to," and if I receive some message indicating that I should drop 
this I will of course comply.
   I apologize if I am violating some protocol here - I looked at what 
seemed to be the relevant documentation, and didn't see anything at the 
time indicating that to be the case.  This seems to be an issue 
affecting both mencoder and mplayer, and I haven't been able to
get on the site to sign up for either list, so I'm trying gmane.  I
looked over the documentation, including the part about known issues,
for some time before saying anything.
   Just so the context is clear (don't misunderstand; this is not a 
VirtualVCR question, as I will explain) I have been using VirtualVCR, 
with ffdshow in constant quantizer mode and with no audio compression, 
in order to get high-quality real-time video capture, and then using 
MEncoder (most recently CVS-050929-14:21-3.4.4, though I saw the same 
problem in 1.0pre7 and 1.0pre7try2, and have never encountered a version 
that didn't have it) to recreate the recordings using slower but less 
bit-hungry settings (lavc and lame with sub-options that I can specify 
if necessary, but, as I will explain, the problem seems to be somewhere 
other than in the codecs).  The initial VirtualVCR output plays back 
with correct A/V sync (or close enough that there is no obvious problem) 
in Winamp and Windows Media Player under Windows and in Xine under 
Linux, but not in MPlayer:  Under Linux, MPlayer shows a gradually 
increasing gap as one seeks farther into the file, progressing to 
obvious alternating periods of silent lip motion and disembodied voices 
by about the 1 1/2 - 2 hour point; under Windows, MPlayer refuses to 
seek at all in the more-than-2-gigabyte MPEG4 avi files, even when 
compiled with --enable-largefiles.  Under both Windows and Linux, 
MEncoder will reencode the files, but the resulting output then shows 
the same progressive desynchronization in Winamp, Windows Media Player, 
and Xine as in MPlayer, even if I use -mc 0 and -noskip.  A given 
segment of the recording will show the same amount of desynchronization 
if I extract it from the original with -ss and -endpos as if I first 
reencode the entire original and then seek within the resulting output 
file.  And if I don't actually reencode at all, but just feed the 
original VirtualVCR recording through MEncoder using -oac copy -ovc copy
-mc 0 -noskip, the output shows the same loss of synchronization in all 
four players, even though the input plays back correctly in all except 
MPlayer.
   Is there some way to override this behavior?  I've been looking over 
the documentation, and haven't seen anything obvious, nor has anything I 
have tried worked so far.  The information needed for correct 
synchronization is apparently present in the original VirtualVCR 
recordings, since the other players all manage it without apparent 
delay, but nothing I've tried yet seems to persuade MPlayer or MEncoder 
to recognize it.  It might be nice if there was a switch or something to 
use Xine's approach to synchronization, since it apparently works with 
some files that the default approach does not.  I guess this is either a 
bug report, a feature request, or a request for information on the 
current features, beyond what appears in the documentation, depending on 
how much of this behavior is intentional and how much can currently be 
overriden.