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

[Michael Niedermayer]

Hi

On Wed, Jan 25, 2006 at 07:33:42PM -0800, Corey Hickey wrote:
> This patch is a new approach in two independent respects.
> 
> 1. The muxer stream timer is left alone, and mencoder.c compensates for
> encoder delay when calculating AV_delay. This doesn't affect the
> functionality of my patch, and it makes it compatible with Michael's
> recent proposed PTS change.
> 
> 
> 2. Rather than setting encoder_delay all at once, this patch increments
> the delay each time a video encoder fails to output a frame, thus
> preventing the video stream timer from being artificially high before
> the encoder has actually buffered that many frames. After the first
> couple seconds, this has no effect, but in my test encodes it does
> prevent a frame-skip my previous patches introduced. To illustrate, here
> are tables of time positions (in secs/frame units) for encoding using
> two B-frames. The first number is the audio, the second is the video. I
> know they don't really get muxed in corresponding pairs, but I wrote it
> that way for clarity; the net effect is the same.
> 
> Input	Output		old-patch	new-patch
> 0, 0	0, 0		0, 2		0, 0
> 1, 1	1, 0		1, 2		1, 1
> 2, 2	2, 0		2, 2		2, 2
> 3, 3	3, 1		3, 3		3, 3
> 4, 4	4, 2		4, 4		4, 4
> 5, 5	5, 3		5, 5		5, 5
> ...	...		...		...
> 
> This might introduce problems I don't know about; if it's a bad idea,
> I'm sure you won't hesitate to tell me. :)
> 
> 
> Now, I still haven't resolved the issue of whether mencoder should
> compensate for anticipated decoding delay. For simplicity, this patch
> doesn't compensate, but I can easily change that. I did make some
> measurements, though: I discovered that I can precisely detect sync
> problems by using framestep in a place where sound (originally) begins
> at the same time a distinctive frame appears. In the case of the
> Serenity trailer, Serenity appears right when a sudden sound begins.
> There are a few 1-frame variations in the desync that I attribute to
> slight vagaries in mplayer's/mencoder's A-V sync code, but overall the
> results are thus:
> 
> 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, ...

[...]

-- 
Michael