Stutter after refresh rate change (1 Viewer)

[nyt]

GOT IT.

Toggling WDM composition will fix playback. However, I'm sure there is a better / proper way to do this. But for now, this works =]

I'll post a patch soon.

 

[Scythe42]

GOT IT.

Toggling WDM composition will fix playback. However, I'm sure there is a better / proper way to do this. But for now, this works =]

I'll post a patch soon.

Great find. Looking forward to try you patch and create test binaries for all the others to test before submitting it to SVN.

 

[nyt]

Before I post the patch using DwmEnableComposition, I'm looking at DwmSetPresentParameters real quick to see if it will be a more elegant solution.

Here's something else I noticed, the refresh rate actually gets set to 23970/1000 whether you request 24hz or 23hz, but the first mode validation fails for 24000/1000, 24000/10001, and 23000/1000. This can most likely be cleaned up, but that's up to scythe.

*** 23 specified
RefreshRateChanger.AdaptRefreshRate: framerate on file C:\movies\28 days later\xmf-28-days-later-1080p-x264.mkv is 23.976
RefreshRateChanger.SetRefreshRateBasedOnFPS: current refreshrate is 60hz - changing it to 23hz
RefreshRateChanger.SetRefreshRateBasedOnFPS: using internal win32 method for changing refreshrate. current is 60hz, desired is 23
W7RefreshRateHelper.SetDisplayConfig(...): SDC_VALIDATE of 23/1 failed
W7RefreshRateHelper.GetRefreshRate: QueryDisplayConfig returned 23970/1000
CycleRefreshRate: successfully changed refresh rate to 23.97Hz (23Hz requested)

*** 24 specified
W7RefreshRateHelper.SetDisplayConfig(...): SDC_VALIDATE of 24000/1000 failed
W7RefreshRateHelper.GetRefreshRate: QueryDisplayConfig returned 23970/1000
CycleRefreshRate: successfully changed refresh rate to 23.97Hz (24Hz requested)

*** 23.976 specified
W7RefreshRateHelper.SetDisplayConfig(...): SDC_VALIDATE of 24000/1001 failed

 

[Scythe42]

Before I post the patch using DwmEnableComposition, I'm looking at DwmSetPresentParameters real quick to see if it will be a more elegant solution.

Here's something else I noticed, the refresh rate actually gets set to 23970/1000 whether you request 24hz or 23hz, but the first mode validation fails for 24000/1000, 24000/10001, and 23000/1000. This can most likely be cleaned up, but that's up to scythe.

This is a driver problem. If the correct way 24000/1001 for 23.976 is not supported - SDC_VALIDATE tests this - the code adds a SDC_ALLOW_CHANGES, which instructs the driver to pick the closest one on its own.

The 23970/1000 is very common at the recent versions of Nvidia drivers, even though they use 23974. They changed it at some point and introduced a ton of more bugs (probably a developer changed, who has no clue about correct refresh rate notations). A few bugs were removed in newer versions but the 24000/1001 and the 60000/1001 bug still remains. I already prepared a bug report for Nvidia (not submitted yet).

So far I have not included additional testing for these bugs, awaiting new driver versions. If they don't show up before 1.1.0 final date is close, I'll add more complex testing, e.g. first 24000/1001, 23976/1000, 23000/1000, 23/1 to cover for driver bugs. But for this I need more feedback from RC1 users what different combinations show up in the logs if people having problems with the latest working driver at that time.

People should only have problems when SDC_ALLOW_CHANGES does not work properly on the driver. Selecting 24Hz should be no problem as 24000/1000 is supported on all drivers I know of. Only 23.976 and 59.994 seem to be the problematic one. I don't have ATI to test and need some ATI test results. If you can supply me with these that would be great! I really need user support here. I also have a binary for testing outside of MP for users with problems who can then test.

As said I wait for feedback of RC1 before adding various try and errors for each refresh rate in hope the notation is fixed within the driver without having to rely on SDC_ALLOW_CHANGES. For Nvidia SDC_ALLOW_CHANGES works great here with all refresh rates since the last driver version. They fixed a bug where 24Hz was complete unselectable among others.

So I am aware of this, and it's on my todo list. It will make the code a little bit more ugly as it iterates through the various combinations (the case statement will be replaced by some ugly if-then-else with loops inside). But it will be done before 1.1.0 if SDC_ALLOW_CHANGES creates problems with recent ATI or Nvidia drivers after RC1 is released.

If you have the capability of testing ATI and Nvidia across various driver versions and cards, we can work together here putting together a list of "driver notations" for 1.1.0 final.

And again thanks for working of the stuttering problem. I'm really looking forward to your patch...

PS: that 24000/1000 is failing for you, is very strange. What card and driver version are you using?

 

[nyt]

Before I post the patch using DwmEnableComposition, I'm looking at DwmSetPresentParameters real quick to see if it will be a more elegant solution.

Here's something else I noticed, the refresh rate actually gets set to 23970/1000 whether you request 24hz or 23hz, but the first mode validation fails for 24000/1000, 24000/10001, and 23000/1000. This can most likely be cleaned up, but that's up to scythe.

This is a driver problem. If the correct way 24000/1001 for 23.976 is not supported - SDC_VALIDATE tests this - the code adds a SDC_ALLOW_CHANGES, which instructs the driver to pick the closest one on its own.

The 23970/1000 is very common at the recent versions of Nvidia drivers, even though they use 23974. They changed it at some point and introduced a ton of more bugs (probably a developer changed, who has no clue about correct refresh rate notations). A few bugs were removed in newer versions but the 24000/1001 and the 60000/1001 bug still remains. I already prepared a bug report for Nvidia (not submitted yet).

So far I have not included additional testing for these bugs, awaiting new driver versions. If they don't show up before 1.1.0 final date is close, I'll add more complex testing, e.g. first 24000/1001, 23976/1000, 23000/1000, 23/1 to cover for driver bugs. But for this I need more feedback from RC1 users what different combinations show up in the logs if people having problems with the latest working driver at that time.

People should only have problems when SDC_ALLOW_CHANGES does not work properly on the driver. Selecting 24Hz should be no problem as 24000/1000 is supported on all drivers I know of. Only 23.976 and 59.994 seem to be the problematic one. I don't have ATI to test and need some ATI test results. If you can supply me with these that would be great! I really need user support here. I also have a binary for testing outside of MP for users with problems who can then test.

As said I wait for feedback of RC1 before adding various try and errors for each refresh rate in hope the notation is fixed within the driver without having to rely on SDC_ALLOW_CHANGES. For Nvidia SDC_ALLOW_CHANGES works great here with all refresh rates since the last driver version. They fixed a bug where 24Hz was complete unselectable among others.

So I am aware of this, and it's on my todo list. It will make the code a little bit more ugly as it iterates through the various combinations (the case statement will be replaced by some ugly if-then-else with loops inside). But it will be done before 1.1.0 if SDC_ALLOW_CHANGES creates problems with recent ATI or Nvidia drivers after RC1 is released.

If you have the capability of testing ATI and Nvidia across various driver versions and cards, we can work together here putting together a list of "driver notations" for 1.1.0 final.

And again thanks for working of the stuttering problem. I'm really looking forward to your patch...

PS: that 24000/1000 is failing for you, is very strange. What card and driver version are you using?

I'm trying to clean some stuff up a bit but have like 5 things going on at once. I have some nvidia cards I can test with but no ATI.

On the ION chip in my HTPC, I cannot use the latest drivers, since the 'resize desktop' option just does not work in the drivers. I run my htpc at 1920x1040 since my screen is 1.85:1. If you're submitting a bug report to them you should put that in there too, heh. I'm still waiting for them to update the ION drivers after they confirmed the report I submitted regarding swapped audio channels (surround and rears are swapped in 7.1). A couple of months ago they said it would be in the next release, but that hasn't shown up yet. Anyway, getting off topic. I have an 800GTX in my desktop, but the displays on it can only do 59/60.

Anyway, adding some logic since not everyone is going to have DWM enabled, then posting patch.

 

[nyt]

Sorry for the delay. Here's the patch. Hopefully this works for everyone.

There may be a better way to do this with DwmSetDxFrameDuration, DwmSetPresentParameters, or DwmSetWindowAttribute. Unfortunately, I don't have the time to mess with this right now, but if you want to, it shouldn't be too hard. Keep me posted how it works.

http://msdn.microsoft.com/en-us/library/aa969540(VS.85).aspx

 

[tourettes]

Sorry for the delay. Here's the patch. Hopefully this works for everyone.

There may be a better way to do this with DwmSetDxFrameDuration, DwmSetPresentParameters, or DwmSetWindowAttribute. Unfortunately, I don't have the time to mess with this right now, but if you want to, it shouldn't be too hard. Keep me posted how it works.

Desktop Window Manager

Scythe, there might be some other interesting parameters to play with (for trying to fix the general stuttering some people are seeing).

 

[Scythe42]

I look at these functions and play around with them. But first I need to test the patch from nyt and provide a test DLL. Then I'll dig something deeper into these functions...

 

[nyt]

I look at these functions and play around with them. But first I need to test the patch from nyt and provide a test DLL. Then I'll dig something deeper into these functions...

I'm trying some of these now as well. Apparently doing it the way in the patch shows desktop after playback briefly.

 

[Scythe42]

I'm trying some of these now as well. Apparently doing it the way in the patch shows desktop after playback briefly.

Yep I noticed, after the RR the disabling/reenabling causes a jump to the desktop until playback begins. But movie runs without stuttering. Looks like you are on the right way for a proper fix.

BTW: this takes about 10 seconds on my machine (caused by subsequent INVALID_MEDIA_TYPE messages). Not related to your patch, but probably a different bug that needs to be investigated on its own.