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
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
|
DetailsThis 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)? |
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.
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.
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.
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.