FS#8264 : mpegplayer: minor rework of A/V sync

FS#8264 - mpegplayer: minor rework of A/V sync

Attached to Project: Rockbox
Opened by Andree Buschmann (Buschel) - Sunday, 02 December 2007, 19:56 GMT
Last edited by Dave Chapman (linuxstb) - Sunday, 30 December 2007, 11:34 GMT

Task Type	Patches
Category	Plugins
Status	Closed
Assigned To	No-one
Operating System	All players
Severity	Low
Priority	Normal
Reported Version	Daily build (which?)
Due in Version	Undecided
Due Date	Undecided
Percent Complete
Votes	0
Private	No

Details

This patch is a first try to get some reasonable rework of the a/v-sync started. As a result the loss in fps when playing synchronized a/v (against pure fps-measurements) has nearly vanished. But I am not sure whether playback is choppier now. What do you think?

Changes:
- calculate the number of video frames which need to be dropped
- reducing and not resetting the frames to skip after dropping the several frametypes
- assumed GOP = 12 frames and P-frame followed by 3 B-frames

ToDo:
- is it possible to read the GOP-structure (number of frames in GOP and number of B's following a P)?

mpegplayer_v01.patch (4.7 KiB)

This task depends upon

Closed by Dave Chapman (linuxstb)
Sunday, 30 December 2007, 11:34 GMT
Reason for closing: Out of Date
Additional comments about closing: Closed at the request of poster due to recent major rewrite of mpegplayer.

Comments (3)
Related Tasks (0/0)

Comment by Michael Sevakis (MikeS) - Monday, 03 December 2007, 08:12 GMT

For answers I'd suggest Googling for the MPEG ISO docs or contact me about it. Also, any info I got regarding what libmpeg2 provided was from browsing the source...there's no real documentation for it.

One problem is that when deciding which frames not to decode, those frames are usually out of order from the presentation order. GOP lengths can vary quite a bit as well as number of pictures between I-frames so assuming 12/3 should be avoided. The main thing is not dropping a bunch of frames at once but dropping in a highly dispersed manner to avoid jumping even if pretty late. Dropping I and P should be considered a desperate sync measure and decoding anyway and dropping in rendering instead should be preferred 2nd after B frames first. We want to drop first what can be dropped at arbitrary times and still allows drawing subsequent frames at arbitrary times and be more severe the later things get.

Comment by Andree Buschmann (Buschel) - Monday, 03 December 2007, 19:02 GMT

I understand. Nevertheless the assumption of 12 frames length for GOP seems quite reasonable as a first shot (the former code assumed 9 frames @25fps implicitly).
The next patch version corrects the subtraction to skip_level within the frame skip as well as re-introduces the render-dropping again. This patch version shows less skippy behaviour than svn (seems to not produce or produce fewer I/D- or P-frame skipping), but will further decrease the real fps as more frames are not rendered at all. Also a/v-sync should be improved as frame- or render-drop starts on 1 frame drift (svn starts at >2.5 frames). I'll test, if a more conversative limit for the allowed drift before dropping frames/rendering is reasonable for fluent video playback.

mpegplayer_v02.patch (5.3 KiB)

Comment by Michael Sevakis (MikeS) - Saturday, 08 December 2007, 10:23 GMT

My intent when writing the dropping code was never solely to maximize frames rendered. The main goal was minimizing the visual impact and there can be a tradeoff between the two. It may appear from the constants that svn starts at >2.5 frames but unless you remove the negative feedback system, this won't actually happen since the later it gets, the earlier it tries to be to make up for it which also naturally places in a negative offset for the time it takes to render frames and decode them.

	Tasks related to this task (0)

Duplicate tasks of this task (0)

Rockbox

FS#8264 - mpegplayer: minor rework of A/V sync

Details

Loading...