Sat 07 Jan 2012 04:22:11 PM UTC, comment #1:
Thank you very much for the useful test file!
I cannot confirm the video delay on my system (I tried Bino, ffplay, and vlc and did not notice a difference). Maybe my ear/eye coordination is just not good enough.
However, there are a few problems with A/V sync and OpenGL:
1. We cannot reliably synchronize to the vertical retrace of the display device. We can (and do) synchronize the vertical retrace with the front/back buffer swap to reduce tearing, but we do not know exactly when this vertical retrace will happen. Therefore, Bino currently assumes that a given frame will be displayed immediately, when in fact it will be displayed at the next vertical retrace. This is one source of A/V sync error, but it is still in acceptable bounds. (Note that the *_OML_sync_control extension would allow precise synchronization to the vertical retrace, but this extension seems to be unsupported in most systems. See http://www.opengl.org/registry/specs/OML/glx_sync_control.txt).
2. Compositing window managers will add a frame delay. When Bino sends a frame to the graphics card, it expects this frame to be displayed immediately (or at least at the next vertical retrace). But with a compositing window manager, the frame will first go to the window manager where it will be used in the compositing engine, and will then later be displayed (typically one frame later). See http://dri.freedesktop.org/wiki/CompositeSwap for more information on this.
The second point may be the reason why I don't experience the video delay: I don't use a compositing window manager. Would you be able to test with compositing disabled, and confirm this?
However, even if we confirm that this is the problem, I'm not sure how to fix this. We may be able to detect a compositing window manager and then expect some guessed delay so that we can take it into account, but I suspect that would be fragile at best...
Any suggestions are welcome.
Martin
|