ashlar42
7th June 2016, 22:45
How to limit the number of drops/repeats with madVR and custom resolutions.
At a basic level, to reach a low enough number of drops/repeats, you need to:
* Increase your refresh rate in case of madVR reporting frames dropped
* Decrease your refresh rate in case of madVR reporting frames repeated.
You will discover that you don't need "perfect" 23.976 refresh rate for smooth playback, as the target refresh varies according to the different clocks in your system.
I simply explain how to do this the right way.
What follows is a guide that hopefully will allow you to maximise playback smoothness using a DirectShow based player with madVR.
Before we begin, I would like to express a heartfelt thank you to hannes69, the Kodi forums user that inspired me to learn this stuff and without whose help this guide would never have happened.
The problem: with PC based playback it's pretty hard to get perfectly smooth playback without the odd frame being repeated or dropped.
The reason this happens is that, unlike regular DVD/BD players, our machines use different clocks inside them. Tipically we are looking at three clocks being used in a PC: video, audio and system clock, with the first two being crucial for video playback.
Unfortunately, it's just a matter of luck for audio and video clock being in sync. When this doesn't happen, we have frames dropped or repeated during playback. More or less frequently according to how much audio and video clock are out of sync.
I think it's better to let madshi speak about this, quoting him from a 2013 post (http://forum.doom9.org/showthread.php?p=1612690#post1612690):There are 3 clocks during video playback:
(1) System clock ("time").
(2) Video refresh rate.
(3) Audio hardware clock.
The system clock really doesn't have anything to do with video playback, but madVR uses it to measure and compare the other two clocks. Now it is possible (even probable) that the system clock is not perfect. But that's not a big problem because if it's e.g. slightly too fast, both video and audio clocks will be measured wrong in the exact same way, so everything's fine.
If the video and audio hardware clocks are "perfect", there should be no dropped or repeated frames (if your PC is fast enough). However, video and audio clocks are usually both imperfect. If both are imperfect in the same way (e.g. being 0.1% too fast), again there's no problem. But if the amount of "deviation from perfectness" of audio and video clocks is not identical then madVR has to either drop frames (video clock slower than audio clock) or repeat frames (video clock faster than audio clock) to make sure video and audio stay in sync.
The refresh rate as shown in the first line in the madVR OSD is madVR's measurement of the video clock, measured by using the system clock. The audio "deviation" in the madVR OSD shows how much the audio clock deviates from "perfectness", measured by the system clock. If e.g. the measured refresh rate is 24.24000Hz (1% too fast for 24.000 content) and the audio deviation is exactly 1%, too, then there should be no frame drops/repeats. If the video/audio deviation differs, there have to be drops or repeats.
In this post madshi gives us all the info we need to try and solve the problem, while acting on the video side. Acting on the audio side means resampling sound so as to "adapt" it to the video clock difference. It's what Reclock does, it's what Kodi does with "Sync to display" activated, it's what Sanear is scheduled to do in the future.
For people who want to bitstream, or who would prefer to leave their audio untouched even when decoding via software, Reclock is not an option, though.
This method acts on the refresh rate you send to your screen, taking into account the interaction between audio clock and video clock discrepancies, compared to the "ideal" refresh rate.
If you follow this procedure, results are not 100% guaranteed as I've discovered some inconsistencies on specific 59.940fps files (while hannes69 has everything working almost perfectly). Nonetheless, even for most problematic cases, we've managed to get the drops/repeats down to less than 1 every two hours. Which, in my book, qualifies as good enough (and for the grand majority of files we are instead down to 1 every 9 hours or more).
The first step is deciding which refresh rate you intend to operate on. I suggest working first on the resolution/refresh that accomodates the majority of content you watch. In the example provided we will use 2560x1440@50.000.
1) Download and install Custom Resolution Utility (CRU) (http://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU).
2) Visit Pixel Clock Calculator (PCC) (http://www.monitortests.com/pixelclock.php).
3) For CRU use the instructions provided by ToastyX in its release thread, linked above.
If you are using audio through HDMI or DisplayPort be sure to add the relevant extension block files in CRU, as explained in the above link. I quote from there below.
For audio support, import one of these extension block files:
hdmi-audio.dat (http://www.monitortests.com/hdmi-audio.dat) (HDMI audio)
hdmi-bitstream.dat (http://www.monitortests.com/hdmi-bitstream.dat) (HDMI bitstreaming for A/V receiver)
displayport-audio.dat (http://www.monitortests.com/displayport-audio.dat) (DisplayPort audio)
What I do is use CRU's Automatic LCD standard timings as a starting point, as those keep the right values for front porch/back porch/sync, setting resolution and refresh and then switching to Manual timings.
Then, using Pixel Clock Calculator I aim for the correct refresh, down to the 5th or 6th decimal (talking about the @ portion in data entry). Under "Maximum decimal places" insert 2, as that, unfortunately, it's the maximum precision offered in controlling the pixel clock in our GPUs.
Comparing the standard LCD timings offered by CRU, fill in the minimum blanking and maximum blanking. As a minimum I tend to use the value offered by standard timings, with 2-300 more pixels as a maximum. Being more precise requires knowing the exact specifications of the screen you are using and it's clearly beyond the scope of this guide. What I suggest is what I've been doing, nothing more.
Keep in mind this:
Active = visible pixels
Front porch + sync width + back porch = blanking
Active + blanking = total
These numbers are *important* if you want to preserve all bitstreaming formats, as they are carried in the "invisible" portion of the HDMI signal (if you're using HDMI, that is). As an example, CEA standard timings require front porch at 638 for 1080p24Hz and 528 for 1080p50Hz.
For the "Multiple" entry, I've found 2 for horizontal and 1 for vertical to be working for me on my plasma TV, while hannes69, on a PC monitor, can use 1 for both horizontal and vertica. Your situation might be different, you can only test here. Suggestion is to start with PCC defaults at 8 horizontal / 1 vertical and slowly decrease the horizontal value if you don't get precise enough results (ie. you don't get refresh rates close enough to what you'll need).
Once you have filled in all the numbers in PCC, hit submit query and find a set of values to use for a new custom resolution in CRU. The three values PCC offers are in line with CRU, so you can use horizontal total, vertical total and refresh (up to the third decimal position) in CRU's window.
http://i64.tinypic.com/24qmsnb.jpg
Front porch and sync width will stay at the values coming from standard timings, back porch and blanking will vary according to the total values you'll input. Save, restart the driver, check that there are no wrong colors, shimmering pixels, distortion (if there are, choose different timings) and move to the following point.
http://i63.tinypic.com/xqdct3.jpg
In the example we aim for 2560x1440, with a refresh rate of 50.000Hz. PCC suggests 2720x1475 lines with a pixel clock of 200.60 MHz. Leading to a calculated refresh rate of 50.000Hz.
4) Find a video lasting at least 45 minutes and start playing it. Leave it playing for at least 30 minutes, more if you can (measurements will be more precise). Note: ReClock is known to produce inaccurate clock deviation figures, even when bitstreaming. For an accurate clock deviation, try Sanear (https://github.com/alexmarsev/sanear/releases) or the default audio renderer.
5) After the prescribed amount of time, bring up madVR OSD (CTRL+J). Take note of the following values, if you want to be rigorous, you might want to start a spreadsheet (or txt, whatever suits you) with these info, name of the file, moment of the day you tested the file (ideally here you should note for how long the PC had been running before the test).
a) movie 50.000 fps (says source filter) - I've had one case where madVR erroneusly reported 23.970 for a 23.976fps file. If something like that happens, change the file, otherwise all calculations would be skewed.
b) 1 frame repeat every x.xx minutes/hours/days (this is the value we wil try to optimize, take note of drop or repeat here, as that's crucial). In the example we get 1 frame dropped every 56.21 minutes. That is 1 frame dropped every (56.21 x 60) = 3372.6 seconds. It appears the audio clock is extremely precise, while the video clock deviates somewhat.
http://i66.tinypic.com/25te2on.jpg
To calculate the error we need to compensate for, the formula is:
1 / (number of seconds before a drop/repeat * movie framerate)
In the above example the formula becomes 1 / (3372.6 * 25.000) = 0.00001186028, that is 11.86028ppm.
To apply the compensation, we add to the refresh rate in case of frames dropped, we subtract from the refresh rate in case of frames repeated.
Given this, our compensated refresh rate in the example becomes:
50.000 * (1+11.86028ppm) ---> 50.000 * (1+0.00001186028) ---> 50.000 * 1.00001186028 = 50.00059301 (we approximate to the eight decimal here).
6) With the compensated refresh rate at hand, we go back to PCC and input it.
7) Now it's again to CRU where we input the new values (use the closer ones you manage to use with no distortion, wrong colors, etc.). For our example, we choose 2750 x 1541 with a pixel clock of 211.89MHz (it's not the closest one, but it's useful for showing you the possible iteration of the process), leading to a calculated refresh rate of 50.00058994Hz.
8) You go back to point 4 and check your new results. 45 minutes of playback and check. Ideally, you'll now find frame drops/repeats in the days range, if not "no frame drops/repeats expected".
9) In our case, instead, we get 1 frame drop every 11 hours.
http://i66.tinypic.com/j8mgrp.jpg
We then decide to go back to 5 and try to compensate some more. With the calculations shown, we get that our error diminished and is now 1.01ppm. That is 1 / ((3600 * 11) * 25)) = 0.00000101. Since we have frame drops, we add to the previous refresh rate like this: 50.00058994 * (1+1.01ppm) = 50.00064044.
Going back to PCC we get a 2860 horizontal total, 1639 vertical total and 234.38 pixel clock custom resolution leading to a calculated refresh rate of 50.00063999. Not perfect but closer. By going back to 4, we get 1 frame drop every 18.15 hours. This is definitely in the "good enough" region, as it offers some serious margin for clock variations due to temperature, etc.
http://i67.tinypic.com/149v8zo.jpg
We could iterate some more or we could be luckier than in this example and have a more precise video clock/GPU/timings relation. The process remains the same. With this configuration the closer I managed to get was 1 frame drop every 1.02 days, with a calculated refresh rate of 50.00067942Hz.
http://i65.tinypic.com/t0n2ht.jpg
Bear in mind that, during our experiments, we discovered that there are some "regions" where the GPU refuses to behave according to the input provided (lowering refresh when timings should make it rise, for instance). If you meet one of those regions, try working around it. Unfortunately, in cases like that, it becomes more a matter of trial and error than it would be ideal.
9) You can now calculate the factor by which the audio and video clock differ. 50.00067942, in our example, is the refresh rate that gives optimal results. The factor then is 50.00067942 / (2 * 25.00), using double the frame rate of the video being played back, as that's what's being displayed by madVR. The calculations gives 1.0000135884. The video clock, in this case, deviates by -13.588ppm, that is 1 - 1.0000135884.
10) You can now apply the factor calculated in the previous point to other refreshes needed. For 23.976, as an example, we would need to aim for 23.976 * 1.0000135884 = 23.97635580. As we discover our PC monitor doesn't accept such a low refresh rate, we double it. 47.952 * 1.0000135884 = 47.95265159. We go back to 3 and discover that with these values we have 1 frame drop every 17.43 hours.
http://i63.tinypic.com/ej9q9.jpg
Most definitely already in "good enough" territory, although we might want to iterate some more as shown above. Doing that, I managed to get to this:
http://i66.tinypic.com/9suuzq.jpg
Bear in mind that clock deviation can vary with temperature (https://en.wikipedia.org/wiki/Quartz_clock#Explanation), so try and get the absolute best result possible as far as drops/repeats are concerned, as that will give you some headroom to handle clock variations due to long sessions playback, room temperature changes, etc. Feel free to take periodic measurements in order to better compensate for the most likely use case.
Again a big thank you to hannes69 for all the knowledge he shared with me. :)
At a basic level, to reach a low enough number of drops/repeats, you need to:
* Increase your refresh rate in case of madVR reporting frames dropped
* Decrease your refresh rate in case of madVR reporting frames repeated.
You will discover that you don't need "perfect" 23.976 refresh rate for smooth playback, as the target refresh varies according to the different clocks in your system.
I simply explain how to do this the right way.
What follows is a guide that hopefully will allow you to maximise playback smoothness using a DirectShow based player with madVR.
Before we begin, I would like to express a heartfelt thank you to hannes69, the Kodi forums user that inspired me to learn this stuff and without whose help this guide would never have happened.
The problem: with PC based playback it's pretty hard to get perfectly smooth playback without the odd frame being repeated or dropped.
The reason this happens is that, unlike regular DVD/BD players, our machines use different clocks inside them. Tipically we are looking at three clocks being used in a PC: video, audio and system clock, with the first two being crucial for video playback.
Unfortunately, it's just a matter of luck for audio and video clock being in sync. When this doesn't happen, we have frames dropped or repeated during playback. More or less frequently according to how much audio and video clock are out of sync.
I think it's better to let madshi speak about this, quoting him from a 2013 post (http://forum.doom9.org/showthread.php?p=1612690#post1612690):There are 3 clocks during video playback:
(1) System clock ("time").
(2) Video refresh rate.
(3) Audio hardware clock.
The system clock really doesn't have anything to do with video playback, but madVR uses it to measure and compare the other two clocks. Now it is possible (even probable) that the system clock is not perfect. But that's not a big problem because if it's e.g. slightly too fast, both video and audio clocks will be measured wrong in the exact same way, so everything's fine.
If the video and audio hardware clocks are "perfect", there should be no dropped or repeated frames (if your PC is fast enough). However, video and audio clocks are usually both imperfect. If both are imperfect in the same way (e.g. being 0.1% too fast), again there's no problem. But if the amount of "deviation from perfectness" of audio and video clocks is not identical then madVR has to either drop frames (video clock slower than audio clock) or repeat frames (video clock faster than audio clock) to make sure video and audio stay in sync.
The refresh rate as shown in the first line in the madVR OSD is madVR's measurement of the video clock, measured by using the system clock. The audio "deviation" in the madVR OSD shows how much the audio clock deviates from "perfectness", measured by the system clock. If e.g. the measured refresh rate is 24.24000Hz (1% too fast for 24.000 content) and the audio deviation is exactly 1%, too, then there should be no frame drops/repeats. If the video/audio deviation differs, there have to be drops or repeats.
In this post madshi gives us all the info we need to try and solve the problem, while acting on the video side. Acting on the audio side means resampling sound so as to "adapt" it to the video clock difference. It's what Reclock does, it's what Kodi does with "Sync to display" activated, it's what Sanear is scheduled to do in the future.
For people who want to bitstream, or who would prefer to leave their audio untouched even when decoding via software, Reclock is not an option, though.
This method acts on the refresh rate you send to your screen, taking into account the interaction between audio clock and video clock discrepancies, compared to the "ideal" refresh rate.
If you follow this procedure, results are not 100% guaranteed as I've discovered some inconsistencies on specific 59.940fps files (while hannes69 has everything working almost perfectly). Nonetheless, even for most problematic cases, we've managed to get the drops/repeats down to less than 1 every two hours. Which, in my book, qualifies as good enough (and for the grand majority of files we are instead down to 1 every 9 hours or more).
The first step is deciding which refresh rate you intend to operate on. I suggest working first on the resolution/refresh that accomodates the majority of content you watch. In the example provided we will use 2560x1440@50.000.
1) Download and install Custom Resolution Utility (CRU) (http://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU).
2) Visit Pixel Clock Calculator (PCC) (http://www.monitortests.com/pixelclock.php).
3) For CRU use the instructions provided by ToastyX in its release thread, linked above.
If you are using audio through HDMI or DisplayPort be sure to add the relevant extension block files in CRU, as explained in the above link. I quote from there below.
For audio support, import one of these extension block files:
hdmi-audio.dat (http://www.monitortests.com/hdmi-audio.dat) (HDMI audio)
hdmi-bitstream.dat (http://www.monitortests.com/hdmi-bitstream.dat) (HDMI bitstreaming for A/V receiver)
displayport-audio.dat (http://www.monitortests.com/displayport-audio.dat) (DisplayPort audio)
What I do is use CRU's Automatic LCD standard timings as a starting point, as those keep the right values for front porch/back porch/sync, setting resolution and refresh and then switching to Manual timings.
Then, using Pixel Clock Calculator I aim for the correct refresh, down to the 5th or 6th decimal (talking about the @ portion in data entry). Under "Maximum decimal places" insert 2, as that, unfortunately, it's the maximum precision offered in controlling the pixel clock in our GPUs.
Comparing the standard LCD timings offered by CRU, fill in the minimum blanking and maximum blanking. As a minimum I tend to use the value offered by standard timings, with 2-300 more pixels as a maximum. Being more precise requires knowing the exact specifications of the screen you are using and it's clearly beyond the scope of this guide. What I suggest is what I've been doing, nothing more.
Keep in mind this:
Active = visible pixels
Front porch + sync width + back porch = blanking
Active + blanking = total
These numbers are *important* if you want to preserve all bitstreaming formats, as they are carried in the "invisible" portion of the HDMI signal (if you're using HDMI, that is). As an example, CEA standard timings require front porch at 638 for 1080p24Hz and 528 for 1080p50Hz.
For the "Multiple" entry, I've found 2 for horizontal and 1 for vertical to be working for me on my plasma TV, while hannes69, on a PC monitor, can use 1 for both horizontal and vertica. Your situation might be different, you can only test here. Suggestion is to start with PCC defaults at 8 horizontal / 1 vertical and slowly decrease the horizontal value if you don't get precise enough results (ie. you don't get refresh rates close enough to what you'll need).
Once you have filled in all the numbers in PCC, hit submit query and find a set of values to use for a new custom resolution in CRU. The three values PCC offers are in line with CRU, so you can use horizontal total, vertical total and refresh (up to the third decimal position) in CRU's window.
http://i64.tinypic.com/24qmsnb.jpg
Front porch and sync width will stay at the values coming from standard timings, back porch and blanking will vary according to the total values you'll input. Save, restart the driver, check that there are no wrong colors, shimmering pixels, distortion (if there are, choose different timings) and move to the following point.
http://i63.tinypic.com/xqdct3.jpg
In the example we aim for 2560x1440, with a refresh rate of 50.000Hz. PCC suggests 2720x1475 lines with a pixel clock of 200.60 MHz. Leading to a calculated refresh rate of 50.000Hz.
4) Find a video lasting at least 45 minutes and start playing it. Leave it playing for at least 30 minutes, more if you can (measurements will be more precise). Note: ReClock is known to produce inaccurate clock deviation figures, even when bitstreaming. For an accurate clock deviation, try Sanear (https://github.com/alexmarsev/sanear/releases) or the default audio renderer.
5) After the prescribed amount of time, bring up madVR OSD (CTRL+J). Take note of the following values, if you want to be rigorous, you might want to start a spreadsheet (or txt, whatever suits you) with these info, name of the file, moment of the day you tested the file (ideally here you should note for how long the PC had been running before the test).
a) movie 50.000 fps (says source filter) - I've had one case where madVR erroneusly reported 23.970 for a 23.976fps file. If something like that happens, change the file, otherwise all calculations would be skewed.
b) 1 frame repeat every x.xx minutes/hours/days (this is the value we wil try to optimize, take note of drop or repeat here, as that's crucial). In the example we get 1 frame dropped every 56.21 minutes. That is 1 frame dropped every (56.21 x 60) = 3372.6 seconds. It appears the audio clock is extremely precise, while the video clock deviates somewhat.
http://i66.tinypic.com/25te2on.jpg
To calculate the error we need to compensate for, the formula is:
1 / (number of seconds before a drop/repeat * movie framerate)
In the above example the formula becomes 1 / (3372.6 * 25.000) = 0.00001186028, that is 11.86028ppm.
To apply the compensation, we add to the refresh rate in case of frames dropped, we subtract from the refresh rate in case of frames repeated.
Given this, our compensated refresh rate in the example becomes:
50.000 * (1+11.86028ppm) ---> 50.000 * (1+0.00001186028) ---> 50.000 * 1.00001186028 = 50.00059301 (we approximate to the eight decimal here).
6) With the compensated refresh rate at hand, we go back to PCC and input it.
7) Now it's again to CRU where we input the new values (use the closer ones you manage to use with no distortion, wrong colors, etc.). For our example, we choose 2750 x 1541 with a pixel clock of 211.89MHz (it's not the closest one, but it's useful for showing you the possible iteration of the process), leading to a calculated refresh rate of 50.00058994Hz.
8) You go back to point 4 and check your new results. 45 minutes of playback and check. Ideally, you'll now find frame drops/repeats in the days range, if not "no frame drops/repeats expected".
9) In our case, instead, we get 1 frame drop every 11 hours.
http://i66.tinypic.com/j8mgrp.jpg
We then decide to go back to 5 and try to compensate some more. With the calculations shown, we get that our error diminished and is now 1.01ppm. That is 1 / ((3600 * 11) * 25)) = 0.00000101. Since we have frame drops, we add to the previous refresh rate like this: 50.00058994 * (1+1.01ppm) = 50.00064044.
Going back to PCC we get a 2860 horizontal total, 1639 vertical total and 234.38 pixel clock custom resolution leading to a calculated refresh rate of 50.00063999. Not perfect but closer. By going back to 4, we get 1 frame drop every 18.15 hours. This is definitely in the "good enough" region, as it offers some serious margin for clock variations due to temperature, etc.
http://i67.tinypic.com/149v8zo.jpg
We could iterate some more or we could be luckier than in this example and have a more precise video clock/GPU/timings relation. The process remains the same. With this configuration the closer I managed to get was 1 frame drop every 1.02 days, with a calculated refresh rate of 50.00067942Hz.
http://i65.tinypic.com/t0n2ht.jpg
Bear in mind that, during our experiments, we discovered that there are some "regions" where the GPU refuses to behave according to the input provided (lowering refresh when timings should make it rise, for instance). If you meet one of those regions, try working around it. Unfortunately, in cases like that, it becomes more a matter of trial and error than it would be ideal.
9) You can now calculate the factor by which the audio and video clock differ. 50.00067942, in our example, is the refresh rate that gives optimal results. The factor then is 50.00067942 / (2 * 25.00), using double the frame rate of the video being played back, as that's what's being displayed by madVR. The calculations gives 1.0000135884. The video clock, in this case, deviates by -13.588ppm, that is 1 - 1.0000135884.
10) You can now apply the factor calculated in the previous point to other refreshes needed. For 23.976, as an example, we would need to aim for 23.976 * 1.0000135884 = 23.97635580. As we discover our PC monitor doesn't accept such a low refresh rate, we double it. 47.952 * 1.0000135884 = 47.95265159. We go back to 3 and discover that with these values we have 1 frame drop every 17.43 hours.
http://i63.tinypic.com/ej9q9.jpg
Most definitely already in "good enough" territory, although we might want to iterate some more as shown above. Doing that, I managed to get to this:
http://i66.tinypic.com/9suuzq.jpg
Bear in mind that clock deviation can vary with temperature (https://en.wikipedia.org/wiki/Quartz_clock#Explanation), so try and get the absolute best result possible as far as drops/repeats are concerned, as that will give you some headroom to handle clock variations due to long sessions playback, room temperature changes, etc. Feel free to take periodic measurements in order to better compensate for the most likely use case.
Again a big thank you to hannes69 for all the knowledge he shared with me. :)