Rockbox

Tasklist

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

Loading...