• 1
  • 230
  • 231
  • 232(current)
  • 233
  • 234
  • 524
Kodi DSPlayer – DirectShow Player for Windows
at this point it would take a detailed guide compiled by advanced user who has fully understood and acted upon the meaning of the procedure, described schematically by Hannes69.
Reply
Quote:Managed to do it, thanks! Feels good not being at the mercy of Nvidia's drivers anymore.

To output correctly I needed to set it up as YCbCr 4:4:4. RGB was messing up the range through HDMI (didn't use to before).
Glad it worked for you. I don´t have any experience with nvidia, with my AMD there´s no range problem and I´m using RGB for all presets.

Quote:Does anyone know of a calculator to show the expected frame drops/repeats based on the clock deviation percentage? Or what would be the formula? I tried "something" but the results made no sense and I suck at math!
I´ll try:
First a simple example. Let´s assume we have a movie with 30.000fps. Let´s assume we have NO clock deviation. Let´s furthermore assume that our real refresh rate is e.g. 28.000Hz. So within one second 30 frames SHOULD be displayed, but because of our wrong refresh rate of 28Hz only 28 frames CAN be displayed. The remaining 2 frames only can be DROPPED.
The other way round: If we have a real refresh rate of 32Hz, and we only have 30 frames, what has to be done? 2 frames of the 30 have to be repeaten to get 32 frames.
So we get "2 frames dropped/repeaten per second" or 1 frame dropped/repeaten in 0.5 seconds.
So the formula if we want the result in hours (1hour = 3600 seconds):

time of dropped/repeaten frames = 1 / (3600 * (real refresh rate - movie framerate)) ; result positive: repeaten frames / result negative: dropped frames.

Now we have to include the clock deviation. The former formula didn´t cover that. We have to replace the expression (real refresh rate - movie framerate) with (real refresh rate - ideal refresh rate).
And as formerly described: ideal refresh rate = movie framerate * (1+ clock deviation)

So whole of the formula:

time of dropped/repeaten frames = 1 / (3600 * (real refresh rate - movie framerate * (1 + clock deviation))) ; result positive: repeaten frames / result negative: dropped frames. Clock deviation can be positive or negative, use the right sign! Clock deviation is given in % in madvr! real refresh rate is in the first line of the OSD of madvr.

You may not get the same results as madvr due to roundings etc. but it should give similar numbers, in my case it works.

Quote:I just deleted my custom resolution for 23.976 and the deviation-% went out of whack. Previously it was ~0.00088% and now way over 0.02000%?!
Hm, here I have no idea. The clock deviation should be independent of the used resolution...

Quote:My .00001% deviation drops a frame every three and a half minutes. This doesn't make sense. The clock deviation can't be accurate.
It could be possible. Let´s take the above formula, take your given numbers and ask for your real refresh rate. I assume we are talking of 23.976fps movie that has to be played back with a 23.976Hz refresh rate. I take your clock devaition of -0.00001% and your "1 frame is dropped every 3,5 minutes".
I get a real refresh rate of 23.97126Hz. So even if you have a very small clock deviation of -0.00001% but you have a "bad" refresh rate of 23.97126Hz you get one frame drop every 3,5 minutes!
As i often described now: You don´t go for low clock deviation (you can´t influence that) and you don´t go for real refresh rates like 23,976Hz, 25.000Hz, 29.970Hz and so on...

What you need is a real refresh rate that takes into account your clock deviation.
Don´t get confused with lucky numbers!
Having almost no clock deviation doesn´t certainly mean you cannot get dropped or repeaten frames, because you can have a bad refresh rate that doesn´t match to you your low clock deviation.
Having a perfect refresh rate setting of e.g. 23.97602Hz doesn´t mean you cannot get dropped or repeaten frames, because you can have a high clock deviation that doesn´t match to your refresh rate.

Or mathematically described: The number of dropped/repeaten frames per time unit depends BOTH of clock deviation and the real refresh rate. What you can´t influence is the clock deviation, this is fix, but you can influence the real refresh rate. And the real refresh rate has to be set in such a way that it eliminates the clock deviation. And this can be achieved by custom resolutions.

Quote:I gave up on trying to describe custom resolutions in the guides I maintain. Two many variables can cause problems and DSPlayer has been less stable, too.
I understand that. The problem is by nature, the thing with custom resolutions and perfect refresh rate is kind of mathematic / scientific thing. And I know that most of the people in this world are at war with mathematics Wink

Quote:Does anyone have a good link on custom resolutions? I'd rather provide a link with great detail than attempt to add this topic to an already packed tutorial. It is really only a tool for advanced users.
Sorry, I have no link or direct description in this matter.
I´m a little bit frustrated that I couldn´t describe it in a better way. I now spent some time here on this topic and until now ashlar seems to be the only one who has understood what I wanted to describe. Maybe it is compexer to understand than I realize or my English is too bad...
In my opinion it is not a VERY advanced topic. There´s some theory behind it, but in practice you only have to do some small calculations and use freeware tools like CRU utility.
For me personally it is way more complex to understand how something like NNEDI upscaling works or how to implement a debanding filter...:Confused But here I have to admit that you can simply activate them in madvr without the need to know how it works...
Reply
I think it's pretty simple, once you understand the underlying concepts.

First of all you launch a video with the fps you want to fix (the fps is kind of irrelevant, as the clock deviation remains the same no matter the refresh rate the card outputs).
You let it play for 15 minutes or so and look at the clock deviation. This is the important variable to know what refresh rate you'll need to aim for.

The deviation is expressed as a percentage, negative or positive.

I'll make two examples for 23.976 refresh (24/1.001). One with a positive deviation of 0.00242%, one with a negative deviation of 0.00242%

Positive clock deviation (0.00242%)

Target refresh rate = 23.97602 * 1.0000242 = 23.976604

Negative clock deviation (-0.00242%)

Target refresh rate = 23.97602 * 0.9999758 = 23.97544

You basically add two decimal positions (zeroes) to the percentage indicated and then add it (positive deviation) or subtract it (negative deviation) to 1. You then multiply that number for the correct refresh rate, in order to get a target refresh rate that compensates your clock deviation. This target refresh rate is the one you need to try and come up with through custom resolutions.
For troubleshooting and bug reporting please make sure you read this first (usually it's enough to follow instructions in the second post).
Reply
@hannes69 (and others familiar with CRU), I described my problem in detail here http://www.monitortests.com/forum/Thread...75#pid5375. Maybe somebody knows what the problem is.
For troubleshooting and bug reporting please make sure you read this first (usually it's enough to follow instructions in the second post).
Reply
Stabilized OSD readings after about 15 mins of a 23.976 movie

Default 23.976 resolution:
"display 23.97005Hz"
"clock deviation -0.02700%"

Custom 23.976 resolution;
"display 23.97625Hz"
"clock deviation 0.00266%" (or thereabouts, forgot to take a screenshot)

Clearly madVR OSD is displaying the "corrected" deviation numbers, not the actual clock deviation (which apparently can't be changed)? Or am I missing something here? It seems to me now like I should try and get the madVR-reported deviation percentage as close to 0% as possible by tweaking the custom resolution, disregarding what numbers "display" gives.
Reply
Hi all,

Been away from the forum for a bit, has there been a DSPlayer build based on 16.1 ive missed?

Cheers in advance

Derek
Reply
Oh, one more thing I don't get:

If I let a clip play for 15 minutes, stabilizing the clock deviation-%, and then skip forward/backward a minute, the deviation continues rushing past what it was supposedly stabilized at before, then gradually slowing down again and setting at a notably different percentage.

What's more, I get different deviation percentages with different 23.976 movies. The difference can be as large as 0.04%. Not sure if that's to be expected or not and whether it has something to do with varying GPU temperatures resulting from varying loads.
Reply
For sure clock deviations change with time and temperature. But no, you DO NOT aim to bring clock deviation to 0. You cannot in any way act on that value. It's based on the internal clocks (quartzs) for video and audio. Those can't be changed. You change the refresh rate (the only thing you can change, really) in order to "trick" video and audio to be in perfect synch (as much as possible).

The values you are reporting seem a bit strange. A Deviation of 0.027 seems too high... are you sure about it? Decimal positions are really important here. If it was 0.0027% it would mean you should be aiming for a custom resolution with refresh rate at 23.9753 (23.97602 * 0.999973). 0.999973 is the result of 1 - 0.000027, as per my examples above.

Thanks to hannes69 I now understand the logic behind this. Audio is reproduced at a certain speed, depending on its clock. The same happens with video. While you can change audio speed with resampling (through Reclock), you might not want do that for different reasons. You are then left with video to act upon. You can't change its clock. But you know how much its clock changes with respect to the audio clock. So you can calculate, as per above, by how much the videoplayback rate needs to be sped up or slowed down. And that's what we basically do with the above process.

Think about PAL DVDs being sped up to 25fps, not only does the audio sound "chipmunky" they also last a little bit less, because video is played back faster as well (25 fps instead of 24/23.976). Here we do not touch audio but speed up or slow down video by the small amount necessary for it to be perfectly synched with audio.

Trust me, I've been HTPCing for the past eleven years... and this is a milestone for me. I've always thought that to get perfect playback one needed Reclock, due to the clock variations between audio and video. But with this process... if I could be sure of the refresh rates selected, even Kodi could get zero drops/repeats with bitstreaming audio, as the math has to stay the same.
For troubleshooting and bug reporting please make sure you read this first (usually it's enough to follow instructions in the second post).
Reply
(2016-05-20, 17:49)Derek Wrote: Hi all,

Been away from the forum for a bit, has there been a DSPlayer build based on 16.1 ive missed?

Cheers in advance

Derek
Yes, I think there is one.

Here you go: http://forum.kodi.tv/showthread.php?tid=...pid2321296
For troubleshooting and bug reporting please make sure you read this first (usually it's enough to follow instructions in the second post).
Reply
@ashlar
Nice explanation of the target refresh rate! Please correct the typo "Target refresh rate = 23.97602 * 0.9999758 = 23.79544" in order to not confuse the people even more Wink
Would be cool if you could explain in such a short compact practical oriented manner the second part of the story concerning the custom refresh rates (I´m not very good in explaining things SHORT Wink

Quote:Clearly madVR OSD is displaying the "corrected" deviation numbers, not the actual clock deviation"
No. Madshi (the author of madvr) explains himself the story about the clocks here, glad I found it.

Quote:the deviation continues rushing past what it was supposedly stabilized at before, then gradually slowing down again and setting at a notably different percentage.
What's more, I get different deviation percentages with different 23.976 movies. The difference can be as large as 0.04%.
There seems something odd in your setup, that´s definitely not the normal behavior. There are small variations (because of heat, electronic effects...) but not that huge. Maybe worth a try to look at the BIOS setting regarding HPET support, this may influence the clocks. No other idea beside that.
Reply
Yes, the deviation was indeed reading -0.02700%, with a frame repeat expected every 34.95 minutes. With the custom res the values look dramatically different, practically resulting in an improvement of one decimal (frame drop expected once in several hours).

As I can't trust what madVR is reporting, it appears the only way to find out the best possible refresh rate for me is to play back the longest movie I have with Reclock disabled and aim for the least drops/repeats. I do need Reclock for PAL speed down though, so maybe I should just stop obsessing over this.
Reply
Just a thought: my video is connected via HDMI to TV while audio goes via optical and quality outboard DAC to analog stereo amp. I assume this could be the source of the the varying clock deviation figures but would someone be able to explain how exactly? Is the same audio clock of an HTPC used for all outputs, for example? Also, I suppose HDMI employs reclocking to correct jitter while optical does not (even though my DAC has very low jitter characteristics and the optical out on my mobo is supposed to be decent too).
Reply
(2016-05-20, 19:46)hannes69 Wrote: @ashlar
Nice explanation of the target refresh rate! Please correct the typo "Target refresh rate = 23.97602 * 0.9999758 = 23.79544" in order to not confuse the people even more Wink
Thanks! It's all to your credit.
Typo corrected, nice catch!
For troubleshooting and bug reporting please make sure you read this first (usually it's enough to follow instructions in the second post).
Reply
(2016-05-20, 21:08)Uoppi Wrote: Just a thought: my video is connected via HDMI to TV while audio goes via optical and quality outboard DAC to analog stereo amp. I assume this could be the source of the the varying clock deviation figures but would someone be able to explain how exactly? Is the same audio clock of an HTPC used for all outputs, for example?
The audio clock in this case is in your motherboard audio chip. The video clock could be a in separate GPU or in an onboard GPU, but it's different from the audio one nonetheless.

When the first videocards with onboard audio through HDMI came out I hoped that they would be using a single clock for both audio and video but, alas, I'm not aware of any that does it.

I used to have spdif out and VGA out, back then. But it was before I really started caring about smoothness in video reproduction. So I'm really in the dark regarding how that influences clock deviation measurements, sorry.
For troubleshooting and bug reporting please make sure you read this first (usually it's enough to follow instructions in the second post).
Reply
(2016-05-20, 19:22)ashlar Wrote:
(2016-05-20, 17:49)Derek Wrote: Hi all,

Been away from the forum for a bit, has there been a DSPlayer build based on 16.1 ive missed?

Cheers in advance

Derek
Yes, I think there is one.

Here you go: http://forum.kodi.tv/showthread.php?tid=...pid2321296

Thanks buddy the link no longer works can someone email it to me or something? be most appreciative to ya Smile Msg me and I'll give you my email addy.

thnx dek
Reply
  • 1
  • 230
  • 231
  • 232(current)
  • 233
  • 234
  • 524

Logout Mark Read Team Forum Stats Members Help
Kodi DSPlayer – DirectShow Player for Windows47