I have implemented yet another sync option (the third and hopefully last one :-)) in MPC-HC (see the MPC-HC GothSync Tryout pages). This variety doesn’t attempt to achieve perfect sync but instead minimizes the effects of imperfect sync.
This alternative is the best option for those who wish to use SPDIF out instead of analog signals (Sync video to display option won’t work) and don’t have a display and a graphics board compatible with PowerStrip (Sync display to video won’t work) or simply can’t match the display rate to the video rate because of display limitations.
 |
| Inevitable judder when presentation time is close to vsync and no sync correction is active. This judder was induced by playing a 25 fps movie with a 50.01 Hz display refresh rate. The green line represents the time when new frames are presented. When the presentation time drifts close to the vsync and passes it (red line) frames may randomly end up right before or right after the closes vsync causing judder as shown in the image. |
This sync alternative minimized the ill effects of poor sync by (1) always presenting a new frame to the graphics board a certain distance from the vsync to avoid tearing and (2) by “snapping” to the closest vsync for as long as possible.
With a few more words: A common cause of visible judder is that a frame’s nominal presentation time is exactly at the start of the vsync. Because of inherent imprecision in the video presentation code, sometimes such frames will be presented right before a vsync and sometimes right after a vsync which means that the frames will not be presented with even intervals. This in turn results in judder as shown in the first image; It takes some time for the renderer to “make up its mind” about on which side of the vsync to present the frame when the difference in rates is small (this particular artifact is actually more pronounced with very closely matching video and display rates) .
 |
| When the Present at nearest vsync is active, there is only one “clean” glitch at vsync. The sync correction keeps the presentation time away from the vsync at all times and lets it only move a full vsync period back or forth when needed, not continuously as in the graph above. In this case we need to show one video frame one extra display cycle now and then to stay in sync why the vsync period gets longer in that “glitch”. |
When turning on the Present at nearest vsync synchronization option, the judder is reduced to one “clean” glitch as shown in the second image. This is achieved by “snapping” the presentation time to the optimal time in relation to vsync (some 8 – 10 ms before vsync) for as long as possible. If the video and the display get more than one frame out of sync, then the “snap” is released and a frame is skipped (if video is running faster) or shown for yet another vsync period (if the display is running faster). Thereafter the “snap” is resumed and the timing is kept at the optimum point until the next time the video and the display get one full frame out of sync.
Once the sync is lost, the algorithm sees to it that the present timing doesn’t shift back and forth in relation to the vsync it is close to thereby eliminating the judder in the image above.
If the display and the video rates are very close, the number of glitches will be small, their effect minimized, and with some luck they won’t happen in the middle of the most critical pan in the movie.
