madVR - high quality video renderer (GPU assisted)

[XMonarchY]

How was nVidia green screen NNEDI3 fixed? Was it the drivers or nVidia contracting madshi to provide a fix???

[madshi]

See for yourself: [...]
Oh, that is a quite big difference, much bigger difference than I expected. Can you now really use twice as demanding algorithms??

Just saw the new build, with the new test build2 render queue is stable here, getting one presentation glitch around 1 min after playback tho, sometimes goin' in fullscreen results in 2-6 presentation glitches.
Sounds good!

Fixed. :)
Great!

Windows 7. Aero enabled. Tearing, yes. Haven't tested disabling that option, but I'm happy to report that with the latest test release it's working correctly, no tearing, both in overlay and non-overlay mode.
Strange, not sure why the previous version would have produced tearing. Anyway, glad to hear it's solved.

Another question: On madshi.net, do you happen to host a text file with just the latest non-test release version number in it? If not, may I ask if it's possible that you place it somewhere? e.g. http://madshi.net/madvr-version.txt
You can check the first post of this thread. The version number listed there is always up to date.

My apologies. :o I've replied to the 3 other bugs.
Thanks. Bug tracker is nicely cleaned up now. Only 3 bugs left to fix in the short term. Two weeks ago it was like 50 bugs or so... :)

Old path never caused me any problems so all I can compare is performance.
With smooth motion disabled, new path is slightly faster, but with SM enabled is a lot slower. OSD comparison here: [...]
That's quite interesting. The SM FRC performance hit seems quite large on your GPU. It must be reaaaally slow... :)

I intended chroma upsampling bluray 23.976 over 1080p display . I hoped that 280x was good enough, but now i am not so sure. Thank you
Might make sense to wait a bit longer before deciding. I hope that maybe someone sooner or later will do some more nVidia and AMD NNEDI scaling comparisons with madVR. Maybe we'll know then...

testing the new windowed mode on my machine with Nvidia GTX295 / Windows 8.1 and I notice a nice improvement in windowed mode.
Good!

One tiny issue I'm sure you'll solve before the final release. When testing with the new "windowed mode" -> "present several frames in advance" disabled. If I enable it mid playback and hit OK, the image freezes.
I don't find it terribly important, after all users will probably decide on the mode once and then never change the setting again. Still, I'd like to look into it. Unfortunately I can't seem to reproduce the problem on my PC, so could you please create a debug log and upload it (zipped) somewhere? Please start playback with the "present several..." option disabled, then change the setting quickly, let the media player stand frozen for 5 seconds or so, then please press the keyboard shortcut to create a freeze report (default: Ctrl+Alt+Shift+Pause/Break), then wait another few seconds until the freeze report appears on the desktop, then close the media player and upload both the debug log and the freeze report. Thanks.

Is it possible for madVR to report Content Type to Display.
Movie, General, Game etc.
I wouldn't know how. I don't think there's an API to do that. I don't even know if HDMI can transport that kind of information.

How was nVidia green screen NNEDI3 fixed? Was it the drivers or nVidia contracting madshi to provide a fix???
doom9 user qduaty provided me with a workaround. There's still a bug in the nVidia drivers but madVR works around it now.

[Werewolfy]

Do you see any improvements over the old mode? Or do both work equally fine for you with no differences worth mentioning?


I can't see a difference, I don't have dropped frames or tearing with the old mode so it's hard to see a real improvement to my eyes. Rendering times seem to be pretty equal too.

[sandman7920]

I wouldn't know how. I don't think there's an API to do that. I don't even know if HDMI can transport that kind of information.


This options is in HDMI >=1.4 standard.

Content type can be changed from nVidia control panel

Display->Adjust desktop color settings->Content type reported to the display (default = auto)

[mark0077]

I don't find it terribly important, after all users will probably decide on the mode once and then never change the setting again. Still, I'd like to look into it. Unfortunately I can't seem to reproduce the problem on my PC, so could you please create a debug log and upload it (zipped) somewhere? Please start playback with the "present several..." option disabled, then change the setting quickly, let the media player stand frozen for 5 seconds or so, then please press the keyboard shortcut to create a freeze report (default: Ctrl+Alt+Shift+Pause/Break), then wait another few seconds until the freeze report appears on the desktop, then close the media player and upload both the debug log and the freeze report. Thanks.

Logs sent via PM. Cheers

[6233638]

One thing I have been noticing recently is increased latency using the new windowed mode whenever I'm interacting with the player. (e.g. pausing the video)
I seem to recall this also happening in FSE mode, so it's likely due to the 16 frames which are queued up to be presented in advance.

Is there any way for madVR to bypass this queue for things like this?

I wouldn't know how. I don't think there's an API to do that. I don't even know if HDMI can transport that kind of information.You can set this in the Nvidia control panel, though I don't know if there's an API for it.
If there is, it would be really nice if madVR could support this.

[Plutotype]

Hi folks,

1. From my knowledge, selecting NNEDI3 within the chroma upscaling section, it basically only doubles the CbCr channel resolution from 4:2:0 to 4:4:4 @original resolution.

2. Then within the image doubling section we take the 4:4:4 video and:
a. double or quadruple ONLY the luma channel ( following particular scaling factor scenario )
b. double or quadruple ALSO the chroma channel ( following particular scaling factor scenario, which can also differ from the luma scaling factor scenario - Q: why would someone need chroma being on different resolution than luma? )

3. Then using the image upscaling / downscaling section we scale the video to the target resolution.

Now practice. If I have 720p 4:2:0 doubled to 1440p 4:4:4 ( using NNEDI3 chroma upscaling first and then luma + chroma NNEDI image doubling ), image upscaler takes then all channels and upscales them to 2160p ( target resolution ).
Or if I have 720p 4:2:0 quadrupled to 2880p 4:4:4 ( using NNEDI3 chroma upscaling first and then luma + chroma NNEDI image quadrupling ), image downscaler takes then all channels and dowscales them to 2160p ( target resolution ).

Please confirm if I get it right.
Thanks.

[QBhd]

correct

QB

[madshi]

I can't see a difference, I don't have dropped frames or tearing with the old mode so it's hard to see a real improvement to my eyes. Rendering times seem to be pretty equal too.
Ok, thx.

This options is in HDMI >=1.4 standard.

Content type can be changed from nVidia control panel

Display->Adjust desktop color settings->Content type reported to the display (default = auto)
Ok, but there's no *Windows* API available for that, AFAIK. There might be an nVidia specific API available, but at this point I'm not ready to go into GPU specific API sets...

Logs sent via PM. Cheers
Does this build fix the problem?

http://madshi.net/madVRwindowedTest3.rar

One thing I have been noticing recently is increased latency using the new windowed mode whenever I'm interacting with the player. (e.g. pausing the video)
I seem to recall this also happening in FSE mode, so it's likely due to the 16 frames which are queued up to be presented in advance.

Is there any way for madVR to bypass this queue for things like this?
I don't think so. You could lower the number of prerendered frames, of course.

why would someone need chroma being on different resolution than luma?
Because doubling chroma costs a lot of performance without bringing a noticeable improvement in image quality. I don't recommend doubling chroma. I've just added the option for people to play with.

[6233638]

I don't think so. You could lower the number of prerendered frames, of course.Well the old rendering path is working fine for me without that issue, so I might stick with that for now.

[YxP]

New path brought dropped frames when flushing options were all set to don't flush. After restoring them to defaults all is well. Visibly very hard or impossible to say if there's any difference.

[webs0r]

Here's a new test build with fixed Overlay and one very small presentation improvement for the new windowed mode:

http://madshi.net/madVRwindowedTest2.rar

@ryrynz, does this one fix the problem? If not, please create a log, as described above, thanks.

Hey this also fixes that issue with the queues and obscuring the player surface with another window. :thanks:

The queues now stay full & there are no frame drops, the only difference is the presentation glitch count goes up when I move the obscuring window.

However, I don't notice any visual problems.

For me, this is now as stable as old windowed mode, happy to run in this mode from now on.

[Knight77]

The last nVidia drivers still have the Limited-Full RGB bug or finally has been corrected ? I don't want to waste time again fixing the install .inf again....

EDIT:
seen this looks like no, any help about it ? ? ? ? ?

"...I'm currently running 335.23 and Nvidia *still* haven't fixed the HDMI 0-255 levels bug. Unbelievable. I owned an Nvidia card years ago when this was a problem and I just assumed it would be fixed by now. Almost every TV on the market supports full RGB mode and Nvidia refuse to let anyone use it and force all HDMI devices to limited 16-235 mode.

The NV_RGBFullRangeToggle.exe doesn't work with newer drivers and registry and inf hacks don't work any more either. AV forums are already full of threads regarding this Nvidia-specific problem and they're about to get a bit more traffic now that the hacks don't work.

I'll let the Nvidia devs in on a little secret - people want to play PC games on their big screen TVs and they *don't* want the blacks and whites chopped off or crushed. FFS..."

[mark0077]

Does this build fix the problem?

http://madshi.net/madVRwindowedTest3.rar

Yes that fixes it, thanks!

[6233638]

I'll let the Nvidia devs in on a little secret - people want to play PC games on their big screen TVs and they *don't* want the blacks and whites chopped off or crushed. FFS..."I think you are confusing the issue.
The issue is that Nvidia will set HDMI to output 16-235 if the display does not report that it supports 0-255.
Madshi's tool should let you force 0-255 output even if your display does not list it as being supported.

The card will not clip levels at all if it's outputting 16-235 - it will result in elevated black levels if there is a levels mismatch.

If you are seeing clipped levels, then you are forcing 0-255 on a display which only supports 16-235.

[Anime Viewer]

You can check you GPU usage with GPU-Z (free download) to make sure which GPU is used.


Actually it's more like luma doubling > chroma upscaling > chroma doubling, but that's for SD content. You results will vary greatly depending on your source and target resolution (and many other things).
For HD content I personally prefer smooth motion over NNEDI chroma upscaling on my 60Hz display, but I am limited by the performance of my Intel HD4000 right now ;)

I launched GPU-Z and confirmed the Nvidia GPU was being used when videos launched. (Before launching the MPC-HC clock speeds were less than 200 mhz, GPU temp was 39*, GPU/memory controller/video engine load was 0%, and memory useage was 0MB. After launching a video GPU core clock shot up to 718mhz, gpu memory up to 900mhz, GPU temp to 58*, GPU load to 41%, memory controller load to 9%, and memory useage (dynamic) to 241mb. I was a bit surprised that Video Engine Load and Memory Usage (dedicated) never increased beyond their zeros).

Oddly luma doubling doesn't want to work without dropping frames no matter what settings I combine with it. I shut off Smooth Motion, turned off Error Diffusion (as well as dithering), and tried every image (and chroma) upscaling option available, and every time frames would drop. The one time they didn't was if I selected DXVA2 for image upscaling, but as I know from reading in the past NNEDI3 is silently disabled when DXVA2 is used for image upscaling in madVR.

Here's a new test build with fixed Overlay and one very small presentation improvement for the new windowed mode:

http://madshi.net/madVRwindowedTest2.rar


Another interesting change with the Test2 (edit: and Test3) is that I'm no longer experiencing dropped frames when using Smooth Motion and NNEDI3 together in extended or duplicate modes with either direct HDMI nor Widi/Miracast. (With the Widi/Miracast connection it now lists presentation glitches instead. :confused: In duplicate mode about 30 presentation glitches a second, and in extend mode 1 presentation glitch about every 4-5 seconds. Again I'm not concerned about Widi/Miracast since I use a direct HDMI cable when I want to watch video on the tv, but its a strange change from what occurred with the original windowed test build).

[SamuriHL]

Well, I've finally had time to play with my new toy and see what it can do. It's an 880m with 8 gigs of ram (yea I know...it's hilarious). Unfortunately, I'm currently stuck with driver version 332.35 as it's the only driver that supports the card for now. If I enable NNEDI3 for chroma, I get the green screen. If I enable it for luma, I get black screen. This is on the latest test3 build. The good news is that the new windowed mode works perfectly. Very stable. I did not have issues with the old windowed mode, so, I can only tell you it hasn't made anything worse. Hopefully nVidia decides to release a newer driver that supports this card soon.

[QBhd]

I just wanted to thank madshi for such an awesome job... again :)

I just finished watching a 1080i episode of TV and the forced film feature of the de-interlacing is spectacular. I have not had a chance to watch such content in about a year and I never tried it the last time, but this time I did and I just wanted to say wow!

Looking forward to donating... keep up the amazing work

QB

[Anime Viewer]

Well, I've finally had time to play with my new toy and see what it can do. It's an 880m with 8 gigs of ram (yea I know...it's hilarious). Unfortunately, I'm currently stuck with driver version 332.35 as it's the only driver that supports the card for now. If I enable NNEDI3 for chroma, I get the green screen. If I enable it for luma, I get black screen. This is on the latest test3 build. The good news is that the new windowed mode works perfectly. Very stable. I did not have issues with the old windowed mode, so, I can only tell you it hasn't made anything worse. Hopefully nVidia decides to release a newer driver that supports this card soon.

Is it on a desktop system, or a notebook? Seems like you have both based on your signature. (Since you wrote 880m I'm guessing its a notebook). Does the system have a built in GPU as well (Intel? thus using optimus)?

You could try going to HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL in the registry and add a new string called forceVendor and give it a value of Nvidia. If it works correctly after the next time you open a video it should add a directory named GeForce GTX 880M inside the OpenCL one. After that your green and back screens while using NNEDI3 should be issues of the past.


Nvidia GeForce 337.50 beta drivers released, anyone want to test these?

http://www.geforce.com/whats-new/articles/nvidia-geforce-337-50-beta-performance-driver

Downloaded, installed and tested. They didn't fix the OpenCL/NNEDI3 issue. (I deleted my forceVendor registry key, and it went back to green screening with NNEDI3 chroma upscaling). (Sadly) I wouldn't be surprised if Nvidia never puts out a fix for the issue, but since madshi's workaround is effective it is not as big a concern as it used to be.

[cyberbeing]

Both madVRwindowedTest2 and madVRwindowedTest seem to have performance and stability issues.

madVRwindowedTest2 produces thousands of presentation glitches when GPU load is high.
madVRwindowedTest doesn't have presentation glitches but the renderer and present queues do not fill when GPU load is high.

Edit: Upon further investigation, this behavior does not seem to have a direct correlation with high GPU load. Rather it may specifically be triggered caused by high refresh rates multiples of 23.976fps video like 96Hz or 120Hz, along with NNEDI3 when compute times are slow enough (one physical CPU core nearly saturated from NVIDIA driver OpenCL CPU wait looping). You've claimed the NVIDIA driver will release this CPU time when required, but maybe it's not fast enough for the present latencies required for the new windowed mode? If you happened to lower the thread priority of the VSync thread, maybe that could be related? Otherwise, maybe it has something to do with the interop workaround? Old windowed mode and FSE are unaffected.

[SamuriHL]

Is it on a desktop system, or a notebook? Seems like you have both based on your signature. (Since you wrote 880m I'm guessing its a notebook). Does the system have a built in GPU as well (Intel? thus using optimus)?

You could try going to HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL in the registry and add a new string called forceVendor and give it a value of Nvidia. If it works correctly after the next time you open a video it should add a directory named GeForce GTX 880M inside the OpenCL one. After that your green and back screens while using NNEDI3 should be issues of the past.




Downloaded, installed and tested. They didn't fix the OpenCL/NNEDI3 issue. (I deleted my forceVendor registry key, and it went back to green screening with NNEDI3 chroma upscaling). (Sadly) I wouldn't be surprised if Nvidia never puts out a fix for the issue, but since madshi's workaround is effective it is not as big a concern as it used to be.

I thought about that but my laptop has an indicator light to show me which gpu is in use. I have LAV set to use cuda. I suppose I can try it. Can't hurt. The thing has enormous power. I'll definitely be playing around with it more.

Sent from my SM-P600 using Tapatalk

[Knight77]

I think you are confusing the issue.
The issue is that Nvidia will set HDMI to output 16-235 if the display does not report that it supports 0-255.
Madshi's tool should let you force 0-255 output even if your display does not list it as being supported.

The card will not clip levels at all if it's outputting 16-235 - it will result in elevated black levels if there is a levels mismatch.

If you are seeing clipped levels, then you are forcing 0-255 on a display which only supports 16-235.

I got that, but anyway since my TV support 0-255 I'd like the drivers to be set that way, but looks like Nvidia drivers still have a bug that force 16-235 no matter what.

Any confirm about how to solve this?

[huhn]

this is not a bug nvidia reads just use what the device tell him. it is just a missing feature amd got.

so a tv with 0-255 support is both or at least should support both it reports it self as limited so nvidia uses limited. the only problem is that you can't change this in the nvidia driver >options<, but you can change this in the registry, just use the tool delivered with madvr (madLevelsTweaker.exe) and it sets the driver this way! they simply didn't add this option in nvidia control center but the driver can change from 16-235 to 0-255.

[THX-UltraII]

I ve heard that it is possible with madVR to correct colors to get a perfect Hue, Saturation and Brightness for all Primary and Secondary colors.

Can someone help me on my way how to do this exactly? My display device has only Greyscale and Gamma correction possiblities. The colors are pretty good already but I like it to get it perfect.

I have a licenced i1 Display Pro III meter and I used Chromapure for my Greyscale and Gamma calibration.

[e-t172]

I ve heard that it is possible with madVR to correct colors to get a perfect Hue, Saturation and Brightness for all Primary and Secondary colors.

Can someone help me on my way how to do this exactly?

See the following:
http://www.avsforum.com/t/1471169/madvr-argyllcms
http://www.argyllcms.com/doc/Scenarios.html#TV1

[StinDaWg]

I think there is a bug with smooth motion enabled and film mode deinterlacing. When playing a 1080i29.97 video it is supposed to IVTC to 23.976 and then match the display rate to 59.94 of your monitor. However with smooth motion enabled the video is extremely laggy, almost like its moving in slow motion. I think it is getting confused and trying to apply smooth motion to the original 29.97 instead of the new 23.976 framerate after IVTC. Render times are less than 5ms so that's not the problem.

[madshi]

New path brought dropped frames when flushing options were all set to don't flush. After restoring them to defaults all is well. Visibly very hard or impossible to say if there's any difference.
Ah, interesting.

Hey this also fixes that issue with the queues and obscuring the player surface with another window. :thanks:

The queues now stay full & there are no frame drops, the only difference is the presentation glitch count goes up when I move the obscuring window.

However, I don't notice any visual problems.

For me, this is now as stable as old windowed mode, happy to run in this mode from now on.
Good to hear!

Yes that fixes it, thanks!
Great!

Well, I've finally had time to play with my new toy and see what it can do. It's an 880m with 8 gigs of ram (yea I know...it's hilarious). Unfortunately, I'm currently stuck with driver version 332.35 as it's the only driver that supports the card for now. If I enable NNEDI3 for chroma, I get the green screen. If I enable it for luma, I get black screen. This is on the latest test3 build. The good news is that the new windowed mode works perfectly. Very stable. I did not have issues with the old windowed mode, so, I can only tell you it hasn't made anything worse. Hopefully nVidia decides to release a newer driver that supports this card soon.
Got nothing to do with the driver. Try Anime Viewer's suggestion, it should work for you.

I just finished watching a 1080i episode of TV and the forced film feature of the de-interlacing is spectacular. I have not had a chance to watch such content in about a year and I never tried it the last time, but this time I did and I just wanted to say wow!
:)

Both madVRwindowedTest2 and madVRwindowedTest seem to have performance and stability issues.

madVRwindowedTest2 produces thousands of presentation glitches when GPU load is high.
madVRwindowedTest doesn't have presentation glitches but the renderer and present queues do not fill when GPU load is high.

Edit: Upon further investigation, this behavior does not seem to have a direct correlation with high GPU load. Rather it may specifically be triggered caused by high refresh rates multiples of 23.976fps video like 96Hz or 120Hz, along with NNEDI3 when compute times are slow enough (one physical CPU core nearly saturated from NVIDIA driver OpenCL CPU wait looping). You've claimed the NVIDIA driver will release this CPU time when required, but maybe it's not fast enough for the present latencies required for the new windowed mode? If you happened to lower the thread priority of the VSync thread, maybe that could be related? Otherwise, maybe it has something to do with the interop workaround? Old windowed mode and FSE are unaffected.
Could be that it's specific to your high refresh rate. FWIW, have you tried resetting the flush settings to the default? The new windowed rendering mode does not use the VSync thread for presentation (unlike the old windowed mode), so the priority of the VSync thread shouldn't matter much. I rather think that Aero runs into trouble with such high refresh rates. You're still on Windows 7? Does the composition rate match the refresh rate? And the queues are always nicely filled, even when those glitches occur?

I got that, but anyway since my TV support 0-255 I'd like the drivers to be set that way, but looks like Nvidia drivers still have a bug that force 16-235 no matter what.

Any confirm about how to solve this?
Yes, you can solve it by using the "madLevelsTweaker" tool.

[madshi]

I think there is a bug with smooth motion enabled and film mode deinterlacing. When playing a 1080i29.97 video it is supposed to IVTC to 23.976 and then match the display rate to 59.94 of your monitor. However with smooth motion enabled the video is extremely laggy. I think it is getting confused and trying to apply smooth motion to the original 29.97 instead of the new 23.976 framerate after IVTC. Render times are less than 5ms so that's not the problem.
If that were a problem, many users would have complained already because the situation you're describing is exactly the main task of film mode. My best guess is that either your splitter or decoder has screwed up, or that the timecodes are screwed up in your video file. Try LAV Splitter + Decoder. If that doesn't help, upload a small sample which shows the problem nicely.

[StinDaWg]

If that were a problem, many users would have complained already because the situation you're describing is exactly the main task of film mode. My best guess is that either your splitter or decoder has screwed up, or that the timecodes are screwed up in your video file. Try LAV Splitter + Decoder. If that doesn't help, upload a small sample which shows the problem nicely.
I'm using LAV, and it's the same for all 1080i29 videos. I'll upload a sample in a bit.

[cyberbeing]

Could be that it's specific to your high refresh rate.
Very likely, though that makes the new Windowed mode rather problematic.

The new windowed rendering mode does not use the VSync thread for presentation (unlike the old windowed mode), so the priority of the VSync thread shouldn't matter much. I rather think that Aero runs into trouble with such high refresh rates.
As mentioned, it does seem like it may have something to do with NVIDIA OpenCL CPU looping or the D3D9 interop, as I cannot seem to trigger this issue with GPU load alone. Does the new Windowed mode present each refresh, rather than each video frame interval?

FWIW, have you tried resetting the flush settings to the default?
Yes, no change.

You're still on Windows 7?
Yes. Later I guess I could boot into Win 8.1 to test there as well.

Does the composition rate match the refresh rate?
Yes.

And the queues are always nicely filled, even when those glitches occur?
Yes, and playback is a stuttering mess.

[madshi]

As mentioned, it does seem like it may have something to do with NVIDIA OpenCL CPU looping or the D3D9 interop, as I cannot seem to trigger this issue with GPU load alone. Does the new Windowed mode present each refresh, rather than each video frame interval?
Yes, it does, same as FSE mode. Basically the new windowed mode is supposed to be a 1:1 copy of FSE mode, just without telling Direct3D to go exclusive.

Later I guess I could boot into Win 8.1 to test there as well.
That would be quite interesting to hear.

Yes, and playback is a stuttering mess.
Well, I don't think there's much I can do then. It's probably a problem somewhere between OpenCL and Aero. Of course you can always simply use the old windowed mode. Fortunately most other users don't seem to have the same problem that you have, so the problem might be isolated to your specific setup. Which means I'll still probably enable the new windowed mode by default in the next build.

[SamuriHL]

Is it on a desktop system, or a notebook? Seems like you have both based on your signature. (Since you wrote 880m I'm guessing its a notebook). Does the system have a built in GPU as well (Intel? thus using optimus)?

You could try going to HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL in the registry and add a new string called forceVendor and give it a value of Nvidia. If it works correctly after the next time you open a video it should add a directory named GeForce GTX 880M inside the OpenCL one. After that your green and back screens while using NNEDI3 should be issues of the past.


Got nothing to do with the driver. Try Anime Viewer's suggestion, it should work for you.


That worked. Thanks, guys! madshi, can this become an option in the UI at some point? Seems like enough of us have this issue.

[cyberbeing]

Fortunately most other users don't seem to have the same problem that you have, so the problem might be isolated to your specific setup. Which means I'll still probably enable the new windowed mode by default in the next build.

Well with most people on 60Hz, I guess make sense. Only people with 120Hz/144Hz monitors and CRTs are likely to be affected, and only when pushing their GPUs very hard with OpenCL.

That would be quite interesting to hear.

The issue with mass presentation glitches does not seem to occur on Win 8.1, though there is some strangeness with the render queue. Depending on how many frames I say to present in advance, the render queue falls and refuses to fill beyond 3-5 under this test scenario.

Present in Advance set to 14-16 = Good
Present in Advance set to 1-12 = Bad

[Anime Viewer]

I think there is a bug with smooth motion enabled and film mode deinterlacing. When playing a 1080i29.97 video it is supposed to IVTC to 23.976 and then match the display rate to 59.94 of your monitor. However with smooth motion enabled the video is extremely laggy, almost like its moving in slow motion. I think it is getting confused and trying to apply smooth motion to the original 29.97 instead of the new 23.976 framerate after IVTC. Render times are less than 5ms so that's not the problem.

What are your other settings? What chroma upscaling are you using? What image upscaling? Are you trying to use image doubling? What is the resolution of the screen you're watching on (ex: 1920x1080)? Are you running the latest madVR version (madVR v0.87.9)? Are you running in FSE mode, or windowed mode? Have you patched that to any of the windowed test builds? If you are running in the new windowed mode with frames in advance, how many frames in advance did you set?

[SamuriHL]

My poor 680 doesn't like NNEDI3 all that much. If I enable image doubling, I drop frames like crazy. I can use it for chroma upscaling. I'll play with it some more but this is with window mode new path. I'll see if FSE makes any difference but I seriously doubt it. I just think my 680 is struggling.

My new laptop with the 880m I've got windowed mode new path, chroma upscaling set to nnedi3, image doubling enabled (32 neurons), error diffusion - option 2, and smooth motion enabled. Jinc 3 for image upscaling/downscaling with AR and linear light scaling enabled. WOW. Just freaking wow. Really really impressive work, madshi.

[e-t172]

madshi: with regard to people reporting frame drop issues in windowed mode and/or old rendering path especially with high frame rates, I'd like to remind you of the GetRasterStatus() (http://forum.doom9.org/showthread.php?p=1673653#post1673653) weird blocking issue. Even though the FRC frame drop issue is fixed, this GetRasterStatus() blocking phenomenon is still very much alive AFAIK.

Specifically, the thing that worries me is that GetRasterStatus() is a function for reporting real-time information about the current VSync status. Consequently, if GetRasterStatus() takes a significant amount of time to return (relative to the VSync interval) then the information it provides becomes useless because by the time it returns it will be way out of date. I've measured GetRasterStatus() sometimes taking 10-15 ms on my machine on these "freeze" events - on 60Hz and higher the VSync interval is 16.16ms or less, which means that the results from the call will be completely bogus. madshi said that this is not very important especially with new rendering paths, but I'm not sure how far that statement goes - if it's so unimportant that missing 15 calls and getting bogus data would not adversely affect madVR operation, then why is madVR calling that function in the first place?

madshi, I believe this issue affects all nVidia GPUs - I can reproduce it on Windows 7 with a 770 and a 780 Ti (GPUs from other manufacturers, however, seem to not be affected). Since you have nVidia GPUs you should be able to reproduce this quite easily just by logging GetRasterStatus() call times. I'm guessing it's a (very persistent) nVidia driver bug but there might be ways to work around it - maybe it only happens as a result of some sort of race condition with the other D3D commands that madVR is issuing, or maybe it can be hacked around by measuring the time each GetRasterStatus() call takes, and then ignoring the results of the call if it takes more than one millisecond - that wouldn't fix the fact that madVR would be deprived of any VSync information during the whole "freeze" period though.

Of course I have no idea how madVR internals look like so maybe I'm just talking nonsense, but I just wanted to remind you that on nVidia GetRasterStatus() seems to behave in very erratic ways and its output cannot be trusted, and that could maybe explain some of the problems that are sometimes reported on this thread. Today or tomorrow I'll try to look at this problem with GPUView which will provide me with much more information than the XPerf traces that I was using when I first investigated this.

[Anime Viewer]

Yes, you can solve it by using the "madLevelsTweaker" tool.

On the topic of the madLevelsTweaker I've noticed it loads with the GPU listed as Intel HD Graphics 4000 even if I set it to run using the Nvidia GPU in Nvidia's control panel. It might be an optimus issue similar to how the Intel was being used in madVR for NNEDI3 unless forced to Nvida in the registry, or perhaps its tied to how the Intel is used in Windows for all function by default and the Nvidia only kicks in on an application by application basis. Its not really an issue, because I can see that RGB levels are successfully adjusted when I have a video open and toggle between the PC levels and TV levels in the properties area of devices in madVR settings.

[StinDaWg]

What are your other settings? What chroma upscaling are you using? What image upscaling? Are you trying to use image doubling? What is the resolution of the screen you're watching on (ex: 1920x1080)? Are you running the latest madVR version (madVR v0.87.9)? Are you running in FSE mode, or windowed mode? Have you patched that to any of the windowed test builds? If you are running in the new windowed mode with frames in advance, how many frames in advance did you set?
I'm running 1920x1080 so there is no scaling for 1080i content. I'm using madVR defaults with bicubic 75AR for chroma, FSE, latest official build.

[madshi]

That worked. Thanks, guys! madshi, can this become an option in the UI at some point? Seems like enough of us have this issue.
I don't plan on adding this to the GUI, but I'd like to make it automatically pick the right GPU. It's on my to do list.

The issue with mass presentation glitches does not seem to occur on Win 8.1, though there is some strangeness with the render queue. Depending on how many frames I say to present in advance, the render queue falls and refuses to fill beyond 3-5 under this test scenario.

Present in Advance set to 14-16 = Good
Present in Advance set to 1-12 = Bad
First of all: Good to hear that Windows 8.1 works better. But the new issue is somewhat strange. That is with windowedTest2 (or 3), right? There was an issue with the original windowedTest build, which sometimes resulted in the queues not filling, but that should be fixed in windowedTest2+.

My poor 680 doesn't like NNEDI3 all that much. If I enable image doubling, I drop frames like crazy. I can use it for chroma upscaling. I'll play with it some more but this is with window mode new path. I'll see if FSE makes any difference but I seriously doubt it. I just think my 680 is struggling.
I would expect the 680 to be fast enough. Depends on the video resolution and the framerate (after deinterlacing), of course.

madshi said that this is not very important especially with new rendering paths, but I'm not sure how far that statement goes - if it's so unimportant that missing 15 calls and getting bogus data would not adversely affect madVR operation, then why is madVR calling that function in the first place?
madVR uses the scanline information to estimate when the next vsyncs will occur. That is very important for the old windowed mode, overlay mode and the old FSE mode. It's also used for the new windowed/FSE modes, but it just needs to be roughly correct for those modes - unless you have smooth motion FRC enabled. SM FRC depends on the vsync estimation to decide which blend factors to use. So it's very important there, too.

The logic I'm using to interpret the scanline results is quite good at filling measurement holes and removing bogus information. Measurements are taken into account for a very long time, so the exactness of the estimation is getting better over time. You can see that by looking at the refresh rate measurement in the OSD. It also gets more exact over time, because it's using the very same vsync estimation results.

maybe it can be hacked around by measuring the time each GetRasterStatus() call takes, and then ignoring the results of the call if it takes more than one millisecond
I've already been doing that for years... ;)

that wouldn't fix the fact that madVR would be deprived of any VSync information during the whole "freeze" period though.
Not a big problem, as long as the measurement hole isn't covering multiple frames. Once I've found out the exact time the next vsyncs are going to be, I can live without new measurements for a short period, because the vsync interval isn't suddenly going to change.

That said, the nVidia GetRasterStatus() problems you noticed might be an indication of some underlying problem, e.g. some parts of the driver getting stuck sometimes. And that could cause those presentation glitches cyberbeing is seeing in Windows 7. But there isn't really anything I can do about it. I'm already using a totally separate D3D9 device just to read the scanline information. I don't know what else I could do.

[SamuriHL]

On the topic of the madLevelsTweaker I've noticed it loads with the GPU listed as Intel HD Graphics 4000 even if I set it to run using the Nvidia GPU in Nvidia's control panel. It might be an optimus issue similar to how the Intel was being used in madVR for NNEDI3 unless forced to Nvida in the registry, or perhaps its tied to how the Intel is used in Windows for all function by default and the Nvidia only kicks in on an application by application basis. Its not really an issue, because I can see that RGB levels are successfully adjusted when I have a video open and toggle between the PC levels and TV levels in the properties area of devices in madVR settings.

I have the same situation on my laptop.

[e-t172]

madVR uses the scanline information to estimate when the next vsyncs will occur. That is very important for the old windowed mode, overlay mode and the old FSE mode. It's also used for the new windowed/FSE modes, but it just needs to be roughly correct for those modes - unless you have smooth motion FRC enabled. SM FRC depends on the vsync estimation to decide which blend factors to use. So it's very important there, too.

Yeah, that's what I thought as well. The SM FRC aspect is interesting; in fact it might explain why I get the impression that SM FRC sometimes produces a small one-frame glitch at random times on my system that looks similar to a lone frame drop, even though the madVR counters don't increase - if it's caused by garbage VSync information then I'm guessing it wouldn't show up in the counters.

Not a big problem, as long as the measurement hole isn't covering multiple frames.

Measurements show that at 60Hz GetRasterStatus() sometimes get stuck for more than a VSync interval. At 120 Hz I'm guessing it would cover several VSync intervals.

That said, the nVidia GetRasterStatus() problems you noticed might be an indication of some underlying problem, e.g. some parts of the driver getting stuck sometimes. And that could cause those presentation glitches cyberbeing is seeing in Windows 7. But there isn't really anything I can do about it. I'm already using a totally separate D3D9 device just to read the scanline information. I don't know what else I could do.

Well I'll see if I can get interesting information from GPUView (which is supposed to be a good tool for diagnosing these kind of low-level D3D issues) and get back if I have anything useful to report. I agree that this seemingly strange symptom might be covering up more fundamental issues down the stack.

[SamuriHL]

I don't plan on adding this to the GUI, but I'd like to make it automatically pick the right GPU. It's on my to do list.


Fair enough. We have it working for now so that's not a problem.


I would expect the 680 to be fast enough. Depends on the video resolution and the framerate (after deinterlacing), of course.


I thought it would be, too. I'll have to play around with it more after work today and see if I can narrow down the cause of the massive dropped frames when I turn it on. Dithering type didn't seem to affect it. This is a 720p60 file I was playing. I tried to mirror what works on my laptop in terms of settings and doesn't seem to be working for the 680. In any case, I'll narrow down the issue.

[cyberbeing]

First of all: Good to hear that Windows 8.1 works better. But the new issue is somewhat strange. That is with windowedTest2 (or 3), right? There was an issue with the original windowedTest build, which sometimes resulted in the queues not filling, but that should be fixed in windowedTest2+.
Yes, I only tested windowedTest2 when I booted into Win 8.1 as I didn't notice there was a 3rd build.

[madshi]

Yeah, that's what I thought as well. The SM FRC aspect is interesting; in fact it might explain why I get the impression that SM FRC sometimes produces a small one-frame glitch at random times on my system that looks similar to a lone frame drop, even though the madVR counters don't increase - if it's caused by garbage VSync information then I'm guessing it wouldn't show up in the counters.
Well, as I said, garbage should be sorted out automatically. The only potential problem would be if the measurement results stop coming in for too long.

Measurements show that at 60Hz GetRasterStatus() sometimes get stuck for more than a VSync interval. At 120 Hz I'm guessing it would cover several VSync intervals.
I don't remember how long the measurement pause can be before madVR resets the estimation math. But you can double check in the debug OSD. The refresh rate indicator changes rather quickly at the start of playback and then after some time calms down and barely changes, anymore. In the moment when madVR resets the estimation math, the refresh rate indicator should go wild again, similar to the start of playback.

I thought it would be, too. I'll have to play around with it more after work today and see if I can narrow down the cause of the massive dropped frames when I turn it on. Dithering type didn't seem to affect it. This is a 720p60 file I was playing. I tried to mirror what works on my laptop in terms of settings and doesn't seem to be working for the 680. In any case, I'll narrow down the issue.
60p consumes 2.5x as much performance as 24p.

[madshi]

Yes, I only tested windowedTest2 when I booted into Win 8.1 as I didn't notice there was a 3rd build.
The 3rd build isn't important, it just fixes a possible freeze when switching between old/new windowed mode during playback.

[SamuriHL]

60p consumes 2.5x as much performance as 24p.

So I see. It's dropping frames on my laptop, as well, on the same file. That's disappointing. LOL.

[madshi]

You can create settings profiles to use different settings for 60p compared to 24p.

[SamuriHL]

You can create settings profiles to use different settings for 60p compared to 24p.

Yea. However, I'm noticing something very very odd. If I play a 720p60 file that causes it to drop frames, switching to the 1080p file I was testing my laptop with earlier without problem continues to show dropped frames. I'll investigate that.

[e-t172]

I don't remember how long the measurement pause can be before madVR resets the estimation math. But you can double check in the debug OSD. The refresh rate indicator changes rather quickly at the start of playback and then after some time calms down and barely changes, anymore. In the moment when madVR resets the estimation math, the refresh rate indicator should go wild again, similar to the start of playback.

Out of curiosity, is there a specific log message being written when that happens?

[madshi]

Out of curiosity, is there a specific log message being written when that happens?
There are different possible error messages in the log:

-------

(1) "CVSync::Evaluate(self: ...) -> not enough data in VSync buffer"

This means that in the last 1000ms there were not enough scanline measurements recorded that can be used for the calculation. Normally it should be several hundreds. E.g. here's a typical information line from a log:

"VSync evaluation; maxTickDif: 0.039ms, items before: 621, items after: 620"

This means that in the last 1000ms there were 620 "valid" measurements recorded, and GetRasterStatus() never took longer than 0.039ms for any of those measurements. This is from windowed playback on Windows 8.1 x64 with my AMD 7770.

(2) "CVSync::Evaluate(self: ...) -> too big gap in VSync detection data to calculate new display refresh rate" or
(2) "CVSync::Evaluate(self: ...) -> too big gap in long term calculation"

These errors occur if there are no measurements for more than 7 vsync interrupts. As long as a measurement gap is shorter than 7 vsync refreshes, madVR will simply ignore the gap, usually without any negative side effects.

(3) "CVSync::Evaluate(self: ...) -> - (scanline estimation failed (estimated: ..., real: ...)"
(3) "CVSync::Evaluate(self: ...) -> long time estimate incorrect"

These occur if internal checks find serious inconsistencies in the vsync estimation.

-------

Generally you can find the VSync estimation entries in the log by searching for "VSyncEvl". That's the name of the thread which is doing the VSync estimations.