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

[Corey Hickey]

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...

-Corey
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fix-bframes-sync4.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20060125/1c06fa6c/attachment.asc>