[MPlayer-dev-eng] [PATCH] mencoder, B-frames, and video/audio delay

[Corey Hickey]

Michael Niedermayer wrote:
>>no B-frames:                            perfect sync
>>with B-frames:                          1-frame video delay
>>x264 with many B-frames and b_pyramid:  2-frame video delay
>>
>>Those numbers confirm the expected decoding delay. The question of
>>whether to compensate in mplayer or in mencoder remains...
> 
> 
> how do you want to compensate this in mplayer? what about xine, vlc, ffplay,
> ffmpeg, wmp, ...

I really have no idea how to compensate in mplayer.... If that's the
right thing to do than I'll try to figure it out, but I can't guarantee
anything.

xine (xine-lib 1.1.1):
I can't compile the latest xine-lib release; sourceforge is being picky
again, so I can't try CVS.

vlc (version 0.8.4):
Looks ok, but I know I can't really notice a 1-2 frame delay at normal
playback speed. VLC disables audio playback when playback speed isn't 100%.

ffplay (CVS)
Has problems with PCM audio -- the audio playback sounds fine, but the
video starts and stops. I've uploaded a sample to:
http://fatooh.org/files/tmp/ffplay-pcm-problem.avi
With MP3 audio instead, the playback is all right, except that lame
encoding delays the audio (if I can fix that later, I will).


WMP (9.0.0.2980)
Reassigned file associations even after I specifically told it not to
(sigh). Doesn't seem to have any playback speed controls, and I really
can't tell if the sync is perfect or not.

Media Player Classic (6.4.8.7)
Disables audio when frame-stepping, but not when playback speed is
slowed. The A-V sync correlates with what I see in mplayer.



So, out of all that, I only got one set of useful data. Nevertheless,
I'm in favor of compensating in mencoder, because, at this point, it
doesn't appear to be the _wrong_ approach, and I know how to do it. I'm
open to other suggestions, though.

-Corey