[madshi]

Originally Posted by jmonier

The way it worked before was:

1. "Apply" was initially greyed out
2. "Test" would cause the new mode to be tested and then return to the previous screen.
3. "Apply" button is now active and would apply the new mode.

I believe that the way it's supposed to work now is:

1. "Test" causes the mode to be tested (so far, this is really no different than before since "Apply" was not an available option then).
2. The Test screen now has an option to save the mode. I believe this is meant to be equivalent to exiting the Test screen and then doing an "Apply". (My opinion is that this is an improvement over the previous method.)

The real problem is that (for me, at least) it does NOT save the mode. If you look at the registry (HKCU.Software.madshi.madVR.DisplayModeMeasurements), the new mode is NOT there.

Spot on right!

(Well, the mode is saved/applied in that way that it's sent to the Nvidia driver, but madVR's own registry storage for the mode is missing, which makes optimization measurements fail.)

Originally Posted by Magik Mark

You have indicated in the latest version that we can track on why refresh rate optimization is not working in certain instances. How do we do this?

By creating a debug log and upload it somewhere for me to look at (don't attach to this forum, please). However, if you look above in this post you'll see that v0.92.4 has a bug which prevent optimization from working with Nvidia GPUs. So it might make sense to wait for v0.92.5 first.

Originally Posted by arrgh

I installed the Intel driver 154519.4678 (zip version) by copying this patched inf (https://mega.nz/#!C811WayR!n6l6R1qW4...yGTxXDaNcEkabA) into the grafics folder and installing manually the driver by choosing this inf; driver signatures of windows must be deactivated;

2D and 3D playback is flashing back (jumping); 2D every 3-4 sec; 3D more, maybe every 2 sec.; if I go from full screen to a window, flashing is constantly present (both in the x64 and x32 versions of the software packages); I have done some screenshots again and used the TracerTool (maybe it helps);
https://mega.nz/#!ylsXTIqA!o_gxDPfx4...l6TcRtDZRnQtR0

http://www.bilder-upload.eu/show.php...1506611058.jpg
http://www.bilder-upload.eu/show.php...1506610827.jpg

I appreciate the effort with the screenshots and freeze reports etc. FWIW, freeze reports are really only useful if the media player is frozen. The screenshots seem similar to the ones you posted a while ago.

But if you want to move this all forward, you really need to start answering my questions. In this post:

https://forum.doom9.org/showthread.p...81#post1816681

I had asked you ""Also"? So this is not a new problem?" but I didn't get a reply to that. I need to know if this is a new problem introduced in the latest madVR builds, or if the problem has always existed.

And in this post:

And in this post I have also asked a couple of questions which you didn't reply to yet:

https://forum.doom9.org/showthread.p...13#post1817413

Originally Posted by el Filou

If it's of interest with anyone with an NVIDIA, Windows 1703 and issues with RGB Full on HDMI to a TV (in this case a Panasonic plasma): I've found a (tedious) workaround to my problem: every time the graphics card causes the TV to resync, i.e. restart or wake up from sleep or change of refresh rate etc., I need to go to NVIDIA Control Panel => Adjust desktop colour settings, and change the Content type reported to the display setting. It actually doesn't matter what I change it to and it has no effect at all on the TV not even a resync, but when I change it to anything other than the current value it magically fixes the levels in RGB Full!
This is definitely a bug with the NVIDIA driver because when I boot into Safe mode or if I uninstall all drivers and switch back to the Microsoft Basic Display Adapter then the levels are always OK.

This seems really bad. I'd suggest that you report this to Nvidia customer support. I've no idea if there's any hope to have this fixed, but reporting is all you can do at this point, I guess.

Originally Posted by mzso

How does that work? I keep pressing it. But nothing happens. (Only the windows prompt for an unresponsive app appears.)

In that case try this tool:

http://madshi.net/madTraceProcess32.zip

(Only works for 32bit media players, though.)

Originally Posted by mzso

Is there any workaround/tweak/hack I can try to get deinterlacing to not break with progDVB?

This problem will be fixed in the next madVR build.

Originally Posted by Telion

Here they are.

Thanks. It's good that you did 6 of them, because only the 6th contained somewhat useful information...

Please let me know if v0.92.5 fixes the issue (when it's released, don't know yet when that will be).

Originally Posted by mzso

Hey now! It looks like I managed to make a couple: https://drive.google.com/open?id=0By...UpvTmg4REhyTG8

Great - thanks! I hope to have this fixed in the next build.

Originally Posted by ryrynz

once madVR gets access to deblocking

Originally Posted by 70MM

Ive been wondering why for a long time why when I upscale Pal DVDs 720x576 to 4K why they never quite fit the left and right side of my motorised masking when set to 4x3. Top and bottom is fine but the left and right sides are less than the masking....

You're saying they're not 4:3, but maybe 3.9:3 or something like that? Must be the fault of the studio doing the encoding then.

Originally Posted by 70MM

I really wish madshi would make some smaller zoom steps e.g. 5%, 10%, 15%, 20%, 25%, this would fix these incorrect sizings from some DVDs on 4x3 material.

Adding smaller steps is on my to do list.

Originally Posted by x7007

Need some help with 23.970 Fps movies. When watching 1080p23.970 movies the sound is a bit off.

Does this problem only occur when using madVR? Or also when using other video renderers? If it also occurs with other video renderers then it can't be a bug in madVR and no configuration option in madVR will help.

Originally Posted by steakhutzeee

What's the difference between 'crop black bars' and 'if there are big black bars'? With the second I can effectively crop the bars away. What about the first?

With "crop black bars" active, madVR actually cuts the black bar pixels away, so madVR has less pixels to process. With "crop black bars" unchecked, madVR is aware of which pixels belong to the black bar and which don't, but the pixels are not cut away, so they're still being processed, they might just be zoomed away, eventually.

Cutting the pixels away will save GPU performance, but it might also cut away TV channel logos and burned in subtitles, which you may or may not want. Hence the option.

Originally Posted by XTrojan

Anyone tried sending HDR metadata through their receiver? I have RX-1040 which has HDMI 2.0, but is said to not support HDR since it doesn't support HDCP 2.2, but madVR has no HDCP.

You can check the "identification" tab in your madVR settings to see if your AVR reports HDR to be supported or not.

Originally Posted by dvd1

because between bilinear the smallest of the scalers and the NGU the most powerful scaler you do not notice any difference. depends on the video card, the fullHD TV or what?
I am inexperienced, how to notice the difference?

Which movie resolution and TV resolution did you test with? E.g. if you play a 1080p movie on a 1080p TV, no scaling is active, anyway, so whether you choose bilinear or NGU doesn't matter. The bigger the upscaling factor, the bigger the visible difference between different scaling algorithms should be. E.g. upscaling a DVD to a 4K TV will look dramatically different with Bilinear vs NGU. But upscaling a 720p movie to 1080p will only show a relatively small difference.

Also the quality of the video matters. If the video is very soft, the difference between Bilinear and NGU will be much smaller than for sharp/detailed videos.

Originally Posted by steakhutzeee

Same movie, first image with MPC-BE with Madvr, second with VLC without Madvr. With Madvr i can notice that the image is too much bright and less detailed as i can see, what i've to change?

First try to reset madVR settings to default. If that doesn't help, in the madVR display device setup try "PC levels" vs "TV levels". Does that help?

Originally Posted by Q-the-STORM

Now I'm trying my luck on getting a custom resolution to work, created a custom 2160p24 mode in the nvidia GUI (I couldn't create the custom mode in madVR, since 24Hz is listed as a standard mode and I couldn't override it, so I created the mode in nvidia's GUI) and then opened a 23.976fps video (over 30min, has audio).

Went to custom modes tab in madVR, the 24Hz mode is correctly being displayed as active and with "custom timings, not measured yet". Pressed the optimize button, got the message I'm supposed to get, clicked OK. So far so good.

Closed madVR options and started to play the video and watched it over 30min, paused and went back to custom modes tab. Still shows "custom timings, not measued yet".

There are 2 problems:

1) Currently you need to create the custom mode with madVR, otherwise the whole optimization procedure doesn't work. I might remove this limitation in the next build, I'm not sure yet.

2) There's a bug in v0.92.4, unfortunately, which stops optimization from working at all with Nvidia GPUs. Will be fixed in the next build.

Originally Posted by Q-the-STORM

Because I can't.

23, 24, 25, 29, 30, 50, 59 and 60 Hz are being listed as "standard mode" and I can't edit them ("GPU driver rejected this mode, for unknown reasons.")

I have the same problem on my PC, it's an Nvidia driver bug. Nvidia is aware of it, and my contact said he'd look into it, but without any ETA.

Generally, in this situation it *seems* that the Nvidia custom mode control panel works, but it doesn't, really. Try rebooting your OS and the custom mode you created through the Nvidia control panel should be gone (it is on my PC). The Nvidia control panel doesn't report failure of the Nvidia custom mode APIs, while madVR does. That's why it seems to work in the Nvidia control panel (but doesn't survive a reboot, or a GPU reset), while madVR properly detects the failure and reports it.

Originally Posted by feelingblue

Has the full/limited issue been fixed with new nvidia drivers?
Selecting RGB Full in both desktop section and video section, is 0-255 correctly displayed?

Which bug? It works fine for me, has for a long time. If all else fails, you can try the "madLevelsTweaker" tool shipping with madVR.

Originally Posted by el Filou

Would it be possible for madVR to store the settings.bin in %ProgramData% ? That folder has the advantage of having write access even for standard users.

IMHO you either want a portable installation or a normal installation. If you want portable, you want the settings file to be in the same folder and definitely not in %ProgramData%. If portable is not necessary, then saving to registry should work just as well as saving to %ProgramData%. So I see no reason to save to %ProgramData%.

Originally Posted by Anime Viewer

I'm noticing small white horizontal dashes (most of the time white, but on occasion black) flash on the screen at what may be random times during playing of videos. I've also noticed they flash on quite frequently (although not always) right after I pause videos too. Its a brief flash, and doesn't remain on the screen making me unable to take a screen shot.
(MadVR, MPC-HC 64, LAV-64, XySubfilter)

I'll post my settings if needed, but before that I thought it may ring a bell to a few of you who may have encountered it yourselves in the past. Any theories on what may be causing it, or a setting I should try changing to remedy it?

Could be a GPU hardware defect (or overclocked VRAM or GPU), or a faulty HDMI cable, or a faulty TV HDMI input port. But this doesn't sound like anything madVR would be at fault for.

Originally Posted by mrmarioman

Quick question.
So what's the better/right option here for HDR movies?

madVR: 0-255 nvidia: 0-255 TV: 0-255
madVR: 0-255 nvidia:16-235 TV: 16-235

in some movies with everything set to full-rgb the blacks look washed out.

See FAQ in 2nd post of this thread.

Originally Posted by bitterman

I seem to have a problem with x265 (H.265) video files.

The image freezes but the audio continues playing, resulting in massive dropped frames.

It happens sporadically.

I made a video about it with madvr statistics enabled.

The decoder queue goes empty in the moment when this happens. Which means that the decoder is not sending madVR any frames in this situation. I'm not sure why, but it doesn't seem like it's likely to be madVR's fault. Have you tried another video renderer like VMR9 or EVR? If the problem also occurs with them, then that would prove that it's not madVR's fault.

Originally Posted by ryrynz

So I'm not having this happen when I select lanczos, although I do see the render and present queue hit zero when I pause the OSD then the render queue fills back up and present queue goes to 1-1, why is it kept so low?

I can't seem to duplicate the freeze with NGU whilst using DXVA2 CB.. but then this is pretty random.. I now can't duplicate using D3D11 either so. *shrug* Guess this is a wait n see.

In paused mode GUI/OSD responsiveness (low lag) is more important than not dropping frames, so the presentation queue is intentionally left almost empty.

It's on my to do list to improve D3D11 decoder handling. This may or may not fix the freeze you've been seeing, I'm not sure.

Originally Posted by pirlouy

Today I've discovered that Motion Interpolation from my Samsung TV causes judder only with madVR and only with 59/60Hz. Strange bug. The strange part is the fact it's only with madVR. With EVR or another player like mpv, 0 judder. I don't know what madVR does which bothers the TV.

Fortunately with 23Hz, 0 problem. And even if I don't like soap opera, the custom settings allows no soap opera and better motion: perfect combination.

Which video fps are we talking about? 24fps or 60fps? madVR is currently not very good at playing 24fps at 60Hz, if smooth motion is disabled. The pulldown interval is pretty random, which may confuse your TV. You should really play 24fps content at 24Hz, not 60Hz. Or alternatively use smooth motion.