- Status Closed
- Percent Complete
- 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
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:
2007-12-30 11:34
Reason for closing: Out of Date
Additional comments about closing:
Closed at the request of poster due to
recent major rewrite of mpegplayer.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
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.
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.
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.