2016-05-13, 00:04
Clock Jitter Explained
Clock jitter is caused by a lack of synchronization between the three playback clocks: the system clock, video clock and audio clock. When the clock speed of the audio and video clocks differ by subtle amounts, occasional clock adjustments must be made during playback to restore audio/video synchronization. This will result in a few dropped or repeated frames occurring as the video plays through its runtime.
The system clock always runs at 1.0x. The audio and video clocks tick away independent of each other. Proper synchronization between the audio and video necessitates that the video clock perfectly matches the audio clock. However, these two clocks will always have some imprecision caused by subtle clock inaccuracies present in any of the chain of A/V hardware, video drivers or playback software that will always produce some deviation from a perfect 23.976 Hz clock speed.
The audio clock is used as the reference clock for video playback. Any difference between the video clock and audio clock in relation to the system clock is indicated by the reported display refresh rate and audio clock deviation displayed in the madVR OSD.
madVR Debug OSD:
Let's use an example:
display (video): 23.97859 Hz
With an ideal value of 23.976 Hz, the 23.97859 Hz rate of the video clock means it is faster than the system clock.
clock deviation (audio): 0.00580%
With a deviation of 0.00580% (23.976 * (1 + [0.00580 / 100]) = 23.97739 Hz), the audio clock is also slightly faster than the system clock. This would be acceptable if the audio clock randomly matched the video clock. However, this is not the case:
audio/video synchronization: 23.977739 Hz (audio) - 23.97859 Hz (video) = -0.000851 Hz (deviation)
The audio and video are out-of-sync. This small deviation would lead to a slow drift between the audio and video during playback. The video clock yields to the audio clock — a frame is repeated or dropped every few minutes to resynchronize.
reported display rate < movie frame rate * (1 +/- [clock deviation / 100]) = dropped frames
The smaller the refresh rate, the larger the repeat frequency = too fast
reported display rate > movie frame rate * (1 +/- [clock deviation / 100)]) = repeated frames
The larger the refresh rate, the smaller the repeat frequency = too slow
Creating a custom mode is a means to improve the synchronization of the video clock in relation to the audio clock. This should result in fewer dropped or repeated frames.
The number of dropped or repeated frames estimated in the OSD should be kept in perspective. In a 23.976 fps source, each dropped or repeated frame only lasts 41.71ms. Most will never manage to notice these occasional hiccups because they are so brief and often blend naturally into the next frame. The actual number of dropped or repeated frames also tends to be a fraction of the total number of frames in the source file.
For example:
In a two-hour, 24 fps movie, there are 172,800 total frames displayed.
120 minutes x 60 seconds/min x 24 frames/second = 172,800 total frames
If a frame is dropped every 12 minutes, this means 10 frames are dropped during the two-hour runtime.
Total Dropped Frames: 120 minutes / 12 minutes per drop = 10 dropped frames
So 10 frames out of 172,800 total frames are dropped.
10 dropped frames / 172,800 total frames x 100 = 0.00579% of all frames in the source are lost.
This amounts to 0.00579% of all frames in the video being either dropped or repeated. That is not to say a perfectionist couldn't strive to improve these numbers by creating a custom resolution with madVR!
Clock jitter is caused by a lack of synchronization between the three playback clocks: the system clock, video clock and audio clock. When the clock speed of the audio and video clocks differ by subtle amounts, occasional clock adjustments must be made during playback to restore audio/video synchronization. This will result in a few dropped or repeated frames occurring as the video plays through its runtime.
The system clock always runs at 1.0x. The audio and video clocks tick away independent of each other. Proper synchronization between the audio and video necessitates that the video clock perfectly matches the audio clock. However, these two clocks will always have some imprecision caused by subtle clock inaccuracies present in any of the chain of A/V hardware, video drivers or playback software that will always produce some deviation from a perfect 23.976 Hz clock speed.
The audio clock is used as the reference clock for video playback. Any difference between the video clock and audio clock in relation to the system clock is indicated by the reported display refresh rate and audio clock deviation displayed in the madVR OSD.
madVR Debug OSD:
Let's use an example:
display (video): 23.97859 Hz
With an ideal value of 23.976 Hz, the 23.97859 Hz rate of the video clock means it is faster than the system clock.
clock deviation (audio): 0.00580%
With a deviation of 0.00580% (23.976 * (1 + [0.00580 / 100]) = 23.97739 Hz), the audio clock is also slightly faster than the system clock. This would be acceptable if the audio clock randomly matched the video clock. However, this is not the case:
audio/video synchronization: 23.977739 Hz (audio) - 23.97859 Hz (video) = -0.000851 Hz (deviation)
The audio and video are out-of-sync. This small deviation would lead to a slow drift between the audio and video during playback. The video clock yields to the audio clock — a frame is repeated or dropped every few minutes to resynchronize.
reported display rate < movie frame rate * (1 +/- [clock deviation / 100]) = dropped frames
The smaller the refresh rate, the larger the repeat frequency = too fast
reported display rate > movie frame rate * (1 +/- [clock deviation / 100)]) = repeated frames
The larger the refresh rate, the smaller the repeat frequency = too slow
Creating a custom mode is a means to improve the synchronization of the video clock in relation to the audio clock. This should result in fewer dropped or repeated frames.
The number of dropped or repeated frames estimated in the OSD should be kept in perspective. In a 23.976 fps source, each dropped or repeated frame only lasts 41.71ms. Most will never manage to notice these occasional hiccups because they are so brief and often blend naturally into the next frame. The actual number of dropped or repeated frames also tends to be a fraction of the total number of frames in the source file.
For example:
In a two-hour, 24 fps movie, there are 172,800 total frames displayed.
120 minutes x 60 seconds/min x 24 frames/second = 172,800 total frames
If a frame is dropped every 12 minutes, this means 10 frames are dropped during the two-hour runtime.
Total Dropped Frames: 120 minutes / 12 minutes per drop = 10 dropped frames
So 10 frames out of 172,800 total frames are dropped.
10 dropped frames / 172,800 total frames x 100 = 0.00579% of all frames in the source are lost.
This amounts to 0.00579% of all frames in the video being either dropped or repeated. That is not to say a perfectionist couldn't strive to improve these numbers by creating a custom resolution with madVR!