Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Plugins
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Buschel - 2007-12-02
Last edited by linuxstb - 2007-12-30

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

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)
Closed by  linuxstb
2007-12-30 11:34
Reason for closing:  Out of Date
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Closed at the request of poster due to recent major rewrite of mpegplayer.

MikeS commented on 2007-12-03 08:12

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.

Buschel commented on 2007-12-03 19:02

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)
MikeS commented on 2007-12-08 10:23

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

Available keyboard shortcuts

Tasklist

Task Details

Task Editing