vertical sync

As long as the display frequency is close to an even multiple of the framerate of the incoming video, the nudges to the reference clock in the new synchronization algorithm described a couple of posts ago can be very small. Sound, video and the display stay in sync.

I tried to adjust the framerate of the video from 25 fps to 24 fps by adjusting the reference clock, a 4% change in rate. This caused the audio to get ahead of the video, i.e. the audio renderer ignored the adjusted rate. But when I speeded up a 23.976 fps movie to 24 fps for display on a 48 Hz screen, a 0.1 % increase in rate, the audio stayed in sync even after two hours into the movie. If the audio renderer had run totally independently, the audio should have lagged about 1 second after 1000 seconds of movie, or so I gather. So maybe the audio renderer does some rate matching after all. I’m a bit confused at the moment and very eager to carry out more experiments. That something works is good. If you know why it works then it is even better.

I let the GothPlayer play an almost 2h long movie from an m2ts file with the new synchronization mechanism (tuning of the incoming stream speed, see the previous post). The movie fps was 23.976 and the display refresh rate was set to 47.95 with PowerStrip (this LCD genuinely synchronizes to 47.95, instead of faking it as some other displays seem to do). The movie resolution was 1920 x 1080 and the display had a 1280 by 720 resolution. The scaling was performed by the video renderer.

The time between the arrival of the sample to the video renderer and the actual vsync stayed between 7.3 and 11.1 ms (the desired value was 10 ms in this case) which means that as long as the graphics board did it’s job, displaying what was gently thrown at it, there should have been no skipped or duplicated frames (I didn’t watch the whole movie – I’ll save that to later). There was no loss of synchronization between video and sound. The player corrected the speed of the video stream 168 times during that time. Filters used:

• Haali Media Splitter
• VMVideo Decoder DMO
• SyncVMR9 custom video renderer
• SyncClock custom reference clock filter
• AC3 Filter audio decoder
• Default DirectSound Device audio renderer (from quartz.dll)

There is a Swedish saying that goes something like “one fly does not make a summer”. The same goes for data points. But it’s a start.

Isn’t it funny how one sometimes get stuck in old thinking. One typical way this happens is that you base a decision on some assumptions, the assumptions change, but there is no “traceability” from your decision to the assumptions so the decision remains intact. It becomes “old thinking”.

This happened to me with GothPlayer, the video player that I’ve been developing on and off the last couple of years. One of the basic assumptions for the main design decision was that I was going to watch TV with it. Since the “claim of fame” of the GothPlayer is that it synchronizes the video and the display (see the GothPlayer pages), that assumption meant that I needed to adjust the display refresh rate. (There was for obvious reasons no way I could adjust the framerate of the incoming TV stream.)

Some more options

I have come to realize that I use my set-top box for all my TV watching. The satellite feed is encrypted by the operator. Perhaps there are TV cards that can decrypt the video but as the set-top box came for free, works fine (it seems to be framelocked), and the SAF (spouse acceptance factor) is much higher than for the HTPC, it stays. The assumption that I need to synchronize to live sources thus goes.

This means that I can leave the display refresh rate alone and adjust the video framerate instead. I can still use the very exact timing information from my renderer as control input. It took me a few hours to implement the alternative solution which is based on an adjustable reference clock generator (the reference clock determines the speed of the video playback).

The big advantage with this solution is that it doesn’t require anything else from your display than that it can synchronize to an exact multiple of the framerate of the video. So computer displays running VGA are fine with the new solution. Also interlaced high-definition displays that seemed hard to get to synchronize with the first sync mechanism work fine with the new.

The new executables and sources files can be found here.

There is one important release note: if you have had the previous version of the player installed, you need to delete all the .ini files typically found under: C:\Documents and Settings\User\Application Data\SyncVMR9, …\SyncPlayer, and …\TestGen. The player may crash the first time if you don’t do this.

Also, the player has not been extensively tested so have some patience. If you do, there is a fair chance that you will get totally tear-free and judder-free fullscreen video. I have.