vertical sync

Renderer preferences dialog

A few more words about what you really do when you adjust those parameters in the renderer preferences of GothPlayer (see figure to the right).

Assume that we are playing a 25 fps PAL DVD and that our MPEG2 decoder thus produces 25 fresh frames per second (some decoders in some modes actually output 50 frames per second but let’s forget about that for now). Also assume that our display refresh rate is set to 50 Hz. This means that if everything is in perfect synchronization, a new frame arrives to the renderer between every other vertical sync pulse (see the figure at the bottom of this post). We want to keep it exactly that way, i.e. we want new frames to arrive well in advance so that there is enough time to do some processing and to send the frame to the video memory of the graphics board to be displayed before the vsync (it is not displayed immediately though, more about that below). This time margin is called Present margin in the renderer preferences dialog to the right and is set to 10 ms in our example.

By adjusting either the timing of the arrival of new frames (when the Synchronize clock alternative is used) or by adjusting the timing of the vertical sync pulses (when the Synchronize display alternative is used), the renderer attempts to keep the Present margin within the Control limits (set to +/- 1.5 ms in the renderer preference dialog to the right).

Now, if the display for instance runs too fast in relation to frame rate of the video, the Present margin shrinks and we need to either slow down the display or to speed up the video.

If using the Synchronize display mode of synchronization, we can slow down the display by adding (invisible) lines or columns to the output from the graphics board. This causes it to take longer to display the frame if the pixel clock is kept constant (the pixel clock determines the number of pixels displayed per second) and the next vsync will arrive later.

If using the Synchronize clock mode of synchronization, we can speed up the video by slightly speeding up the clock that effectively determines the flow of time in the player application. This makes new frames arrive at a slightly higher frequency, i.e. earlier.

As mentioned above, a new frame is not displayed immediately when it has been sent to the graphics board’s video memory. It is instead entered into a buffer that queues up frames for display a few vsyncs later. One advantage of using such a buffer is that we avoid drawing in the memory that we are currently displaying. If we did that, we might end up showing parts of two different frames at the same time and get image tearing. The buffer also levels out effects of small glitches in the timing. In the figure, the effect of triple buffering is illustrated. In triple buffering there are three “slots” in the buffer: one that is currently displayed (called the front buffer), one into which we write the next frame and one there in between.

I added two more functions to GothPlayer:

• Process priority for the player can be set in the player preferences.
• The cursor is hidden when entering fullscreen mode (there are no menus available anyway).

There is a new version of GothPlayer for download here.

Improvements

• Triple buffering for added robustness of the video – display synchronization.
• More complete trace information in the on-screen display for checking the quality of the video – display synchronization.
• TV playback is now verified (again).
• More reliable toggle between windowed mode and fullscreen mode.
• More keyboard shortcuts.
• The function for changing the speed of the video (within less than or equalt to +/- 1%) is now better and should not affect the sound quality. A speed shift of more than 1% or so will make audio and video lose sync though so this function should not be used for instance to shift 25 fps to 24 fps. I will later see if I can combine Reclock and GothPlayer to accomplish both perfect sync and a speed shift with resampling of the audio.
• Toggling between the two sync modes (“Synchronize display” and “Synchronize clock”) is more robust now and can be done while the player is streaming.
• There is a new function and an instruction for how to measure the discrepancy in speed between the video and the display (the “Drift”).

I have tested the player successfully with a four core AMD Phenom + ATI 3450 and a single core Intel + NVidia 7600, both running Windows XP.

For more information and a kind of a manual, see this page and its subpages. I appreciate feedback as always.

Known issues

• The reference clock uses the system clock which has a granularity of 1 ms and may have an inaccuracy of more than that. I haven’t seen any adverse effects of this but I will later implement a more accurate reference clock.
• The cursor still shows in fullscreen and needs to be “parked” at the right side of the screen or so.
• The interface with PowerStrip is not foolproof. If you quit PowerStrip in the middle of the fiddle, you may end up with a slightly off refresh rate (that the player last used to control the display).

A screenshot of the GothPlayer 1.4 in windowed mode. The on-screen info is only used for performance monitoring and can of course be turned off.