madVR - high quality video renderer (GPU assisted)

[Aleksoid1978]

I do some check - in window mode all fine, true 24p mode(with custom mode for 23.976). In FSE - 24p broken, only 24p is broken ... I do not understand I changing the display mode before create FSE mode.

P.S. MPC-HC - have the same issue. Maybe some parameters wrong in calling IDirect3D9Ex::CreateDeviceEx() for FSE, can you show how you fill D3DPRESENT_PARAMETERS and how you call CreateDeviceEx(), what parameters use ??

[madshi]

Well, as I said, Direct3D might change the display mode when switching into FSE mode. So you may have to call ChangeDisplaySettingsEx() again after entering FSE mode (maybe with a small delay). Or alternatively you could try to stop Direct3D from changing display modes by using ugly hacks like API hooking or stuff like that. But it's probably nicer/cleaner to let D3D do its thang, and then just overwrite it again by calling ChangeDisplaySettingsEx() again. It's all quite ugly, in any case. I wish Direct3D would allow us to choose whether it should change the display mode or not.

[Aleksoid1978]

Originally Posted by madshi

Well, as I said, Direct3D might change the display mode when switching into FSE mode. So you may have to call ChangeDisplaySettingsEx() again after entering FSE mode (maybe with a small delay).

Something wrong, It don't help. Event if i call ChangeDisplaySettingsEx() after create FSE - also have 23.976, not 24p.

[madshi]

Well, not sure what it is then. Maybe the OS thinks Direct3D already switched to the correct mode, and you then calling ChangeDisplaySettingsEx() afterwards makes no difference because the OS thinks "I'm already in that mode, so I don't need to do anything". What happens if you switch to a totally different mode first, and then afterwards to the real mode? E.g. try 60p first, then 24p. Then it will probably work, but it's ugly...

Originally Posted by madshi

The VSync reset stuff might have had a part in this, as well. Here's a new test build:

http://madshi.net/madVR8810test6.rar

This time it's a release mode build. So please double click "activate release mode.bat" first, then replace the madVR.ax file. Then please just double check if this test build still fills the queues with your current settings (4 frames pre-presented). If it does, as is well. If it doesn't, the VSync reset stuff is still a problem. I don't need a log this time. Just the information whether this build still fills the queues for you, or not. Thanks.

test5 created a huge file on my desktop, probably because de-bugging was enabled. Its there a way to disable that in test6???

[The 8472]

Originally Posted by madshi

Linear light should produce the "correct" result, unlike gamma light. The reason is that blending pixels together in gamma light is mathematically not correct. And downscaling blends a lot of source pixels together for each target pixel. For upscaling it's a bit different. In theory linear light should produce more correct results for upscaling, too, but it adds so much ringing that the positive benefits are outweighed.


All 2-tap algos should be fine. However, 3-taps and more produce a lot of ringing when using linear light which the anti-ringing filter doesn't completely erase. Other than the ringing, using 3-taps/4-taps for linear light downscaling is ok, too. It's really only the ringing which is the key problem.


Hmmmm... Isn't that backwards? I mean don't we have to think of linear light as a straight line, and of gamma light as a curve? Jensen's inequality should prove that *gamma light* produces incorrect results, not linear light. Or am I missing something? You seem to suggest that gamma light is a straight line and that linear light is a curve. But I think it's exactly the other way round? Images/videos are using gamma light because that's how CRTs used to work, and also because it happens to approximate the way our eyes perceptually work. But nature/physics really is linear light, not gamma light.

I have very little understanding on the correctness of the underlying processing, but I've found this thread on the imagemagick forum to provide a nice reference of examples. Especially the perceptually uniform (LAB/LUV) colorspaces in comparison to either linear or gamma light.

Also, Nicolas' concolusion from that thread:

(SPOILER ALERT: Don't read this if you don't want the way you look at the images to be influenced.)
Generally, the linear light colour spaces (linear RGB and XYZ) produce exaggerated dark halos, and the "perceptual" colour spaces (sRGB, LAB, LUV) produce exaggerated light halos.
If you think about it for a minute, this makes complete sense, because the perceptual colour spaces pack lots of bits at the darker end of the intensity spectrum, and "hollow out" the lighter end, so as to mimick the HVS (Human Visual System). So, 1 unit of dark overshoot gets you less "far" in sRGB than in linear RGB, but 1 unit of light overshoot gets you less "far" in linear RGB than sRGB.
Sigmoidization treats dark and light overshoots equally, and generally dampens both.

[AngelGraves13]

Originally Posted by Aleksoid1978

Well, what then watch a movie with a frequency 23.976 ??
Nvidia don't have a mode for 23.976 fps ))

P.S. we are talking about FSE.

Isn't 23Hz NVIDIA's 23.976 mode? It works perfect on my end.

[Telion]

Originally Posted by The 8472

I have very little understanding on the correctness of the underlying processing

There is a nice article on this matter. (Giving an archived link since the original site seems to be down right now.)

[cyberscott]

Originally Posted by madshi

The VSync reset stuff might have had a part in this, as well. Here's a new test build:

http://madshi.net/madVR8810test6.rar

This time it's a release mode build. So please double click "activate release mode.bat" first, then replace the madVR.ax file. Then please just double check if this test build still fills the queues with your current settings (4 frames pre-presented). If it does, as is well. If it doesn't, the VSync reset stuff is still a problem. I don't need a log this time. Just the information whether this build still fills the queues for you, or not. Thanks.

This build doesn't completely fill the pre-presented queue, but almost. It fills it to 2-3/4. Just to make sure, I switched back to using madVR8810test5.ax (in debug mode) and rechecked it. Test 5 pre-presented queue filled up and stayed consistently at 4-4/4.

[cyberscott]

Originally Posted by XMonarchY

test5 created a huge file on my desktop, probably because de-bugging was enabled. Its there a way to disable that in test6???

Make a copy of "activate debug mode.bat" Rename it to "activate release mode.bat" Activate it in your madVR folder and you should get a pop-up saying "release mode successfully activated" then your log file will stop being generated.

[madshi]

Originally Posted by XMonarchY

test5 created a huge file on my desktop, probably because de-bugging was enabled. Its there a way to disable that in test6???

Those test builds were made for one specific purpose only: To find a bug. They were not meant for actual use.

Originally Posted by The 8472

I have very little understanding on the correctness of the underlying processing, but I've found this thread on the imagemagick forum to provide a nice reference of examples. Especially the perceptually uniform (LAB/LUV) colorspaces in comparison to either linear or gamma light.

Those are comparison for upscaling. We were talking about downscaling, which is a very different situation, especially when talking about large downscaling factors.

Originally Posted by cyberscott

This build doesn't completely fill the pre-presented queue, but almost. It fills it to 2-3/4. Just to make sure, I switched back to using madVR8810test5.ax (in debug mode) and rechecked it. Test 5 pre-presented queue filled up and stayed consistently at 4-4/4.

<sigh> Ok, I know what to do then. I just hope it won't negatively affect other users...

Originally Posted by cyberscott

Make a copy of "activate debug mode.bat" Rename it to "activate release mode.bat" Activate it in your madVR folder and you should get a pop-up saying "release mode successfully activated" then your log file will stop being generated.

Every time you double click those batch files, the actual madVR*.ax files get swapped around (renamed). So when dealing with test builds, these batch files are actually "dangerous" because you might accidently swap the test build away and use the official build instead, which defeats the purpose of using the test build. Each madVR*.ax file is either a release or debug build. You can't change that, you can just rename the files, which is what those batch files do.

[jaju123]

I have a green bar across the top with the AMD W10 drivers in windows 8.1 found here: http://forums.guru3d.com/showthread.php?t=399595

Happens for all W10 driver builds.
Everything is all the wrong color and weird too.

[cyberscott]

Originally Posted by madshi

<sigh> Ok, I know what to do then. I just hope it won't negatively affect other users...


Every time you double click those batch files, the actual madVR*.ax files get swapped around (renamed). So when dealing with test builds, these batch files are actually "dangerous" because you might accidently swap the test build away and use the official build instead, which defeats the purpose of using the test build. Each madVR*.ax file is either a release or debug build. You can't change that, you can just rename the files, which is what those batch files do.

I hope it won't cause any negative issues for others as well.

Thanks for the explanation of the batch files. I didn't fully understand how it worked. Now the madVR [debug].ax files makes perfect sense to me!

[Budtz]

Originally Posted by Aleksoid1978

Well, what then watch a movie with a frequency 23.976 ??
Nvidia don't have a mode for 23.976 fps ))

P.S. we are talking about FSE.

Why is this nvidia 23.976 bug not fixed? Does anyone know?

[ryrynz]

Madshi, any chance of releasing a test build that includes the other fixes (88.11)?

Originally Posted by Budtz

Why is this nvidia 23.976 bug not fixed? Does anyone know?

Would really like to see true 23.976 output also.. I'll just have to accept frame repeats, frame drops are terrible, especially if you have some motion interpolation enabled.

[InstantAli3n]

Originally Posted by ryrynz

Madshi, any chance of releasing a test build that includes the other fixes (88.11)?



Would really like to see true 23.976 output also.. I'll just have to accept frame repeats, frame drops are terrible, especially if you have some motion interpolation enabled.

Is this what's causing ReClock to act weird? Because since 0.88 came out ReClock will not detect framerate automatically anymore.

Or maybe it's just that ReClock is garbage because devs are too busy supporting bloatware. (Had to be said). I mean if it's so hard why not just have a "set to nearest major framerate" option.

[ryrynz]

with D3D 11 enabled present frame for every vsync on or off if I enter the madVR properties page whilst a file is playing back
the render queue drops to nothing and video stutters until the video is paused and played again Latest Nvidia driver on W8.1
This is with FSE enabled, no issues in windowed mode.

[MysteryX]

You guys have been talking a lot about debanding recently. Without starring at the details, here's what I personally found.

The new debanding algorithm seems to make the image sharper, which I like, whereas the old algorithm leaves it a bit blurrier.

That's probably just looking at the edges which is what stands out. From what I've been reading, it seems the details are the opposite: the new algorithm blurs them out while the old algorithm smooths them.

So yeah... at first sight, the new algo looks better.

THe new algo definitely has a greater visual impact. It does much more than debanding but it's not clear what it's actually doing. The one thing I don't like about deband is that its rendering time varies between videos which makes it hard to configure so that it doesn't lag. There's always one video where it causes frames to drop.

[MysteryX]

Hey Madshi, you managed to get a lot of stuff going that isn't currently possible in AviSynth. I'm wondering, how different is it to program for a DirectShow Filter than for AviSynth?

For example, how difficult would it be to port SuperRes to AviSynth?

Or, would it be very difficult to plug madVR into an AviSynth filter? That may be ideal as it would give access to all madVR features.

[nevcairiel]

Originally Posted by MysteryX

Or, would it be very difficult to plug madVR into an AviSynth filter? That may be ideal as it would give access to all madVR features.

madVR is a video renderer, you cannot ever use it from AviSynth.