madVR - high quality video renderer (GPU assisted) [Archive] - Page 586

ADude

1st May 2015, 23:33

If there was a way, using the Profiles, to choose "no upscaling" as the choice of algorithm, then madVR does not have to detect anything or make a choice as to how close is close enough to not upscale.

Instead the user could use Profiles (I already have the profile setup for "1076" in order to use a lesser quality, better performance algorithm) to choose "no upscaling" whenever they thought appropriate.

huhn

1st May 2015, 23:44

STaRGaZeR

1st May 2015, 23:59

@madshi, @e-t172

There's a *dramatic* difference between a solution which is based on the hardware VSync interrupt, and between trying to present at the right time by using a software solution. I think the current madVR FSE mode ends up utilizing the VSync hardware interrupt, which is what makes it so reliable. The software solution simply can't work as well, because Windows is not a real time OS.

How can you say there is a dramatic difference between a solution based on the VSync hardware interrupt and just "software" if you are not sure you're using the former?

My experience when testing madVR is that FSE mode usually works well but every once in a while I see a clear frame duplication and when I check the stats I see nothing in there, like it never happened, but it clearly did. Just like windowed mode really.

Asmodian

2nd May 2015, 00:17

There's a *dramatic* difference between a solution which is based on the hardware VSync interrupt, and between trying to present at the right time by using a software solution. I think the current madVR FSE mode ends up utilizing the VSync hardware interrupt, which is what makes it so reliable. The software solution simply can't work as well, because Windows is not a real time OS.

I was talking about the difference between the theoretical variable refresh rate with a driver provided queue with a timestamp for when to present each frame and a pure madVR controlled queue using the timestamp for when to present. eg:
As already stated, GSnyc / Freesync would make sense for video playback if they implemented a queue where you can define the time a frame should be presented. Without this with my programming knowledge you would get rather high amounts of jitter, of course not mentioning what happens if something else needs CPU time. I think MadVR could spin the CPU to achieve good timings, buuuuuuut thats a more than ugly soution.

I don't think this driver queue with timestamp would have much of an advantage over madVR; there is still no hardware clock control of the present. V-sync is obviously very different.

You are aware, though, that FreeSync does not work with HDMI? Doesn't that automatically rule out 99.999% of all TVs and projectors out there today?

Actually FreeSync does not work with 100% of TVs and projectors out there today, neither variable refresh rate technology works without specific support (new hardware) in the display. DP 1.2a or 1.3 alone isn't enough.

I would really like the topic of FreeSync/G-Sync to be stopped. If I were a mod I would ban this topic from this thread. It's coming again and again, usually restarted by the same users. And it goes on my nerves. I've posted my opinion several times, and there's really zero use restarting the discussion again (unless there's important new information available).

Ok, I will not mention it again in this thread unless there is important new information. :(

huhn

2nd May 2015, 00:35

Nope. At least if I don't keep it in "normal size" all the time. And I don't cause I use to play many in lower resolutions.
sorry but that is doing the same... set a hotkey.

Really? I only saw "No, not yet".

how are you interpreting "No, not yet"?

it's like ~going to happen but not soon/now~.

ADude

2nd May 2015, 03:03

i'm not saying this so this feature will not be added. I'm just giving you a very simple alternative.

only the player can currently say madVR to not upscale at all. you can use ffdshow profile that add black boarder this should work too and that automatic i'm pretty sure there was an option for this.
I'm talking about a madVR Profile (not an ffdshow profile).

madVR does the upscaling, so presumably a madVR Profile can specifiy "skip upscaling" and the code just jumps to after the upscaling portion.

The point is that you are specifying a human being to read what resolution is used, and then press a button. In actuality a 1970s computer can do this, so it is ridiculous to ask the human to do something much simpler than all the rest of the software does.

(BTW, I have not updated my sig in a while and often use other players than MPC-HC)

Qaq

2nd May 2015, 07:35

sorry but that is doing the same... set a hotkey.

how are you interpreting "No, not yet"?

it's like ~going to happen but not soon/now~.
Maybe you shouldn't speak for madshi too much?

madshi

2nd May 2015, 08:50

How can you say there is a dramatic difference between a solution based on the VSync hardware interrupt and just "software" if you are not sure you're using the former?
I can say that a plane is faster than a bicycle, even if I don't fly at all. In the same way I can say that utilizing a VSync interrupt is dramatically better than using a software based page flipping model on a non-realtime-OS. Both are facts.

It's hard to be 100% sure about something the OS does if you don't have the OS source code. However, there are hints in various places in the Microsoft documentation and header files, if you know where to look. And there's the fact that unlike Windowed mode, the FSE mode never tears. Which is a pretty good indication that FSE mode flips backbuffers via VSync interrupt.

Ok, I will not mention it again in this thread unless there is important new information. :(
Thank you, appreciated.

Maybe you shouldn't speak for madshi too much?
His interpretation is correct, though.

e-t172

2nd May 2015, 09:50

I don't think this driver queue with timestamp would have much of an advantage over madVR; there is still no hardware clock control of the present. V-sync is obviously very different.

Depends on how it's implemented. If there is hardware support for it, this "driver queue with timestamp" could be implemented using a dedicated hardware clock, maybe even the same video clock that's used for fixed refresh rates. That would solve the problem. In any case, the hardest part if getting the GPU manufacturers to listen.

I can say that a plane is faster than a bicycle, even if I don't fly at all. In the same way I can say that utilizing a VSync interrupt is dramatically better than using a software based page flipping model on a non-realtime-OS. Both are facts.

It's hard to be 100% sure about something the OS does if you don't have the OS source code. However, there are hints in various places in the Microsoft documentation and header files, if you know where to look. And there's the fact that unlike Windowed mode, the FSE mode never tears. Which is a pretty good indication that FSE mode flips backbuffers via VSync interrupt.

Another tell-tale sign is that it's easy to observe (through drift) that the VSync events are not following the CPU clock, they're following a different clock (in this case the hardware video clock). That wouldn't be the case if VSync was triggered from the CPU.

huhn

2nd May 2015, 09:52

I'm talking about a madVR Profile (not an ffdshow profile).

madVR does the upscaling, so presumably a madVR Profile can specifiy "skip upscaling" and the code just jumps to after the upscaling portion.
it's not that easy.
The point is that you are specifying a human being to read what resolution is used, and then press a button. In actuality a 1970s computer can do this, so it is ridiculous to ask the human to do something much simpler than all the rest of the software does.

(BTW, I have not updated my sig in a while and often use other players than MPC-HC)

you can do this fully automatic with ffdshow and the player doesn't matter it simple has to be able to load ffdshow.

madshi

2nd May 2015, 11:04

@madshi: I found that RivaTuner Statistics Server prevents madTPG from running it doesn't even show its window, just leaves ghost process. It happens when "Custom D3D support" is enabled, even if madTPG.exe is on exclude list and/or statistics are disabled completely. I didn't know where to report this issue, but I figured it might be better if you contact RTSS developer with more information if you care about this issue. Or just fix/workaround the issue. :)
Can't reproduce that on my PC. Using Windows 8.1 x64, installed RivaTuner Statistics Server version 6.2.0, enabled "Custom Direct3D support", restarted the Statistics Server, just to be safe. madTPG starts fine. Without even adding it to the exclude list. Any ideas how I could reproduce the issue?

kasper93

2nd May 2015, 13:06

No, not really. I'm using v6.3.0 which is bundled with latest MSI Afterburner https://gaming.msi.com/features/afterburner##downloads and "Custom Direct3D support" is enough to trigger the issue. But if you can't reproduce, just leave it. I don't think this is very important, anyway.

MS-DOS

2nd May 2015, 16:27

latest madVR build (work in progress) with its new D3D11 presentation path

How are the D3D11 <-> OpenCL interop costs on AMD there? :)

madshi

2nd May 2015, 17:00

It's a presentation path, not a rendering path. OpenCL is rendering, not presentation, so no changes there.

flashmozzg

2nd May 2015, 17:13

Some "stupid" question here but is oGL rendering viable at all? Would be cool to have cross-platform madVR. Or even better with vulkan and oCL 2.1 which have common intermediate representation.

ADude

2nd May 2015, 20:19

you can do this fully automatic with ffdshow and the player doesn't matter it simple has to be able to load ffdshow.

I'm using LAV filters in everything now (and btw thanks to nevcairiel for making them available for free to everyone).

madshi

2nd May 2015, 20:49

Some "stupid" question here but is oGL rendering viable at all? Would be cool to have cross-platform madVR. Or even better with vulkan and oCL 2.1 which have common intermediate representation.
It would probably cost me months of development time, and then, in other OSs there's no DirectShow. Which means that every media player has its own rendering logic. So even if I made madVR available to other OSs, every media player would have to do *a lot* of code changes to support madVR. After my experience with the XBMC developer team I don't think madVR would be very welcome by most cross-platform media player projects, simply because they already have their own renderer and adding support for madVR would be a major headache to them. So there you have 2 key arguments why there's pretty much zero chance to port madVR to other OSs, at this point in time. Even if one of these arguments would become moot, chances would still be very low.

huhn

2nd May 2015, 21:20

I'm using LAV filters in everything now (and btw thanks to nevcairiel for making them available for free to everyone).

using it as a raw video filter together with lavfilter is no option right?

flashmozzg

2nd May 2015, 22:38

It would probably cost me months of development time, and then, in other OSs there's no DirectShow. Which means that every media player has its own rendering logic. So even if I made madVR available to other OSs, every media player would have to do *a lot* of code changes to support madVR. After my experience with the XBMC developer team I don't think madVR would be very welcome by most cross-platform media player projects, simply because they already have their own renderer and adding support for madVR would be a major headache to them. So there you have 2 key arguments why there's pretty much zero chance to port madVR to other OSs, at this point in time. Even if one of these arguments would become moot, chances would still be very low.

Thanks for the reply. DX it is then)

MS-DOS

2nd May 2015, 23:49

It's a presentation path, not a rendering path. OpenCL is rendering, not presentation, so no changes there.

Are you planning to make a D3D11 rendering path somewhere in the future too?

MysteryX

3rd May 2015, 00:52

I just realized that when playing 1080p videos on 1080p display with MPC-HC + SVP + madVR, I'm getting an average rendering time of 13ms and max stats rendering of 25ms which goes up to 75ms.

Why does max stats vary so much? Shouldn't every frame take the same amount of time to generate? This causes dropped frames. I though it was SVP's fault, but apparently it's madVR's fault.

I'm using Windows 7 x64 with Radeon HD 7670M

Playing videos of lower resolution works fine: max stats are stable.

huhn

3rd May 2015, 01:24

ryrynz

3rd May 2015, 01:25

Are you planning to make a D3D11 rendering path somewhere in the future too?
It's in the works judging from one of Madshi's recent posts.

MysteryX

3rd May 2015, 01:42

try to use a very high present queue.
What do you mean?

I just tried madVR without SVP. Rendering times are 10.4ms and max stats are stable. Which means there's a conflict of some sort with SVP.

huhn

3rd May 2015, 01:49

you find that option under: rendering -> exclusive mode settings or windowed mode settings.

what ever you use.

Asmodian

3rd May 2015, 02:28

What do you mean?

I just tried madVR without SVP. Rendering times are 10.4ms and max stats are stable. Which means there's a conflict of some sort with SVP.

SVP uses the GPU as well and you need to take madVR's reported rendering times as an estimate. I suspect you are simply hitting the performance limits of your GPU.

James Freeman

3rd May 2015, 04:45

JarrettH

3rd May 2015, 04:50

I think windowed overlay makes the switch to full screen instantaneous and present several frames in advance will fill the buffers before play begins. Sorry it's not a complete answer :P

James Freeman

3rd May 2015, 04:56

Also, what is this "new windowed mode" people talking about?
I don't see anything named like that in madVR settings window...

jkauff

3rd May 2015, 06:05

Also, what is this "new windowed mode" people talking about?
I don't see anything named like that in madVR settings window...
It's not so "new" anymore. If you go back about a year in the thread, you'll find madshi's posts about revamping madVR's windowed mode.

FireFreak111

3rd May 2015, 06:08

huhn

3rd May 2015, 12:10

Any idea why I would be getting a consistent frame repeat every 38.36 seconds? This seems to be for all 23.976hz material, on a 60hz display with smooth motion. My display runs at 60.005hz by the looks of it, and this occurs both in fullscreen exclusive and windowed overlay, and old p[ath. It moves to every 9.5 minutes at 59.94hz Is this expected?

everything is working as intend here.

first of all you shouldn't get a repeated from with SM but the OSD will still calculate this number for you.

set your display to 60hz press control + r and wait over 1 min you will not see a a repeated frame.

huhn

3rd May 2015, 12:17

I see a lot of discussion about "enable windowed overlay", "present several frames in advance" and "new windowed mode".
Can someone please explain these please?
Also I read FSE "fullscreen exclusive", what are the benefits of this? it it overlay too?
present frames in advance is the new windowed/fullscreen mode.
windows 7 overlay is something even more different.
fullscreen excluive takes full control of the presentation and it has the least chance to be interrupted.
I have always used "enable windows overlay" to keep Color Management in windows working along with MadVR 3dLUT.
When "enable windows overlay" is deactivated MadVR takes control of the color management of windows too, and disables ICC profile if "disable GPU gamma ramps" is activated.
I guess overlay just bypasses Aero?

why do you activated disable GPU ramps if you want to use the low quality windows CMS?

What would the benefits of D3D 11 to 9?

Thanks

for example 10 bit output.

FireFreak111

3rd May 2015, 12:45

everything is working as intend here.

first of all you shouldn't get a repeated from with SM but the OSD will still calculate this number for you.

set your display to 60hz press control + r and wait over 1 min you will not see a a repeated frame.

Makes sense. I was getting dropped frames, not repeated, but that is likely a seperate issue. Since this is for a plasma TV, I used the Nvidia control panel, manipulated the timings and got 23.976 (1% of the time, the other 99% is 23.97598hz, which is definitely within margin of frame drops I am willing to accept. Better than 23.973hz. No repeated frames, 1 every 2 days, and no need for smooth motion anymore. And this is in fullscreen overlay mode, not exclusive. I am going to test to be sure the display hasn't replaced any possible SM blur with judder.

Combined with bitstreaming, WASAPI Exclusive (for AAC/FLAC in anime, MPC-BE has a fixed Audio Renderer), 64 bit chain and the windowed overlay + present in advance setup, playback is amazing. Well done madshi, you have created an exceptional renderer. This community has created an amazing package for quality video playback.

James Freeman

3rd May 2015, 18:03

present frames in advance is the new windowed/fullscreen mode.
Thank you.
Any benefits over the old one?

fullscreen excluive takes full control of the presentation and it has the least chance to be interrupted.
So I understand that this is the most reliable mode for testing and comparing with other modes....?
This is also the fastest mode right?

why do you activated disable GPU ramps if you want to use the low quality windows CMS?
Actually, when windows 7 overlay mode is enabled (which it is) the GPU ramp is completely bypassed and left alone so this option doesn't do anything.
In other words, 3DLUT does its magic with curves and gamut correction without effecting the windows Color Management when overlay mode is active.
In other words, Overlay bypasses windows Aero (I think) and Color Management which is exactly what I want.
Also, the "disable GPU gamma ramps" is still effective with "disable calibration controls for this display" but only for the overlayed picture inside the player.
So its clear that when overlay mode is active in madVR, all the options only effect the overlayed window, which is a great feature.

for example 10 bit output.
Sweet, madshi is already preparing for UDH Blu-Ray...
I still use my trusty Dell U2410 which has 10-bit via DisplayPort, but I never been able to use it.

madshi

3rd May 2015, 18:35

Are you planning to make a D3D11 rendering path somewhere in the future too?
Rendering is already mixed right now, with D3D9 shaders, OpenCL stuff (NNEDI3) and DirectCompute stuff (error diffusion). Other than that, I usually don't like to comment on future plans.

I just realized that when playing 1080p videos on 1080p display with MPC-HC + SVP + madVR, I'm getting an average rendering time of 13ms and max stats rendering of 25ms which goes up to 75ms.
I think SVP can be configured to either use the CPU, only, or to also use the GPU via OpenCL. In the latter case madVR and SVP will have to share the GPU power, and everytime SVP uses the GPU, madVR will have less GPU power available, so that's why the max rendering stats are changing.

Max stats shouldn't matter as much if you use fullscreen exclusive mode, and if you use a large CPU and GPU queue and a large number of prepresented frames. In the end, for madVR the most important thing is that the queues stay decently filled (say at least 4-5 frames for all queues, the more the better) at all times. As long as that is the case, I would expect madVR to produce smooth results - at least in FSE mode.

It's in the works judging from one of Madshi's recent posts.
I never said anything of the sort. I said a D3D11 *presentation* path is in the works, not a D3D11 *rendering* path.

Combined with bitstreaming, WASAPI Exclusive (for AAC/FLAC in anime, MPC-BE has a fixed Audio Renderer), 64 bit chain and the windowed overlay + present in advance setup, playback is amazing. Well done madshi, you have created an exceptional renderer. This community has created an amazing package for quality video playback.
Glad you like it!

Thunderbolt8

3rd May 2015, 19:09

Combined with bitstreaming, WASAPI Exclusive (for AAC/FLAC in anime, MPC-BE has a fixed Audio Renderer), 64 bit chain and the windowed overlay + present in advance setup, playback is amazing. Well done madshi, you have created an exceptional renderer. This community has created an amazing package for quality video playback.are you using reclock for wasapi exclusive? if so, I thought reclock only works in 32-bit mode?

mrbinky

3rd May 2015, 19:19

who sad you have to use nnedi3 in the first place.

a HD 4400 can run madVR easily.

edit:
if mpc-hc crash there should be a crush dump in the mpc-hc folder(or here: C:\Users\"your user name"\AppData\Roaming\MPC-HC) or a madVR crash report on your desktop.
32 bit work right? think about using this in the meantime.

OK, I've got some crash files, but no way to upload them, as, even when compressed, they are >2 megs. Any suggestions?

OK, I just submitted a bug report and uploaded the crash file.

Blackfyre

3rd May 2015, 19:32

I think SVP can be configured to either use the CPU, only, or to also use the GPU via OpenCL. In the latter case madVR and SVP will have to share the GPU power, and everytime SVP uses the GPU, madVR will have less GPU power available, so that's why the max rendering stats are changing.

Yep, MysteryX, exactly what Madshi said here... For example I use Source Multiplied by 4x for Target Frame-Rate for SVP, I have to make sure my GPU usage with Madvr is below 25% (Use AfterBurner to monitor your GPU usage)... Once SVP runs at 4x, my 17% GPU usage becomes 68% usage.

As for what you were being told earlier by another user (regarding the GPU Queue Size). Go to Madvr settings, click on general settings for Madvr (under rendering sub-menu)

and it's the bottom two sliders (I have CPU queue size set to 128, and GPU queue size set to 16), I also recommend you tick (enable) the below settings in the same area for a better experience with SVP.

"delay playback start until render queue is full"

"delay playback start after seeking, too"

"enable automatic full-screen exclusive mode"

Everything else should be un-ticked (disabled).

FOR Smooth Motion (under sub-menu rendering), enable smooth motion frame rate conversion and set it to always on.

huhn

3rd May 2015, 20:13

Thank you.
Any benefits over the old one?

So I understand that this is the most reliable mode for testing and comparing with other modes....?
This is also the fastest mode right?
they should be slower but more reliable. at least in my tests.

Actually, when windows 7 overlay mode is enabled (which it is) the GPU ramp is completely bypassed and left alone so this option doesn't do anything.
In other words, 3DLUT does its magic with curves and gamut correction without effecting the windows Color Management when overlay mode is active.
In other words, Overlay bypasses windows Aero (I think) and Color Management which is exactly what I want.
Also, the "disable GPU gamma ramps" is still effective with "disable calibration controls for this display" but only for the overlayed picture inside the player.
So its clear that when overlay mode is active in madVR, all the options only effect the overlayed window, which is a great feature.

for me windows 7 overlay mode is altered as all other modes.
and only disable GPU gamma ramps disables windows calibrations nothing else.

Asmodian

3rd May 2015, 21:28

Actually, when windows 7 overlay mode is enabled (which it is) the GPU ramp is completely bypassed and left alone so this option doesn't do anything.
In other words, 3DLUT does its magic with curves and gamut correction without effecting the windows Color Management when overlay mode is active.
In other words, Overlay bypasses windows Aero (I think) and Color Management which is exactly what I want.
Also, the "disable GPU gamma ramps" is still effective with "disable calibration controls for this display" but only for the overlayed picture inside the player.
So its clear that when overlay mode is active in madVR, all the options only effect the overlayed window, which is a great feature.

While Windows 7 Overlay mode does bypass the GPU ramps the option does still do something. Without the option madVR will load the ramps from the GPU and apply them with its own processing, emulating the GPU ramps. "disable GPU gamma ramps" disables this emulation so you need to specifically create a 3DLUT without gamma ramps to use with this option.

I do agree, it is great that when using Overlay "disable GPU gamma ramps" only applies to madVR. You can use only a 3DLUT for correction in madVR and still have basic correction for the rest of Windows.

madshi

3rd May 2015, 21:44

Qaq

3rd May 2015, 22:21

are you using reclock for wasapi exclusive? if so, I thought reclock only works in 32-bit mode?MPC-BE (including x64) has its own WASAPI Excl. Works fine.

FireFreak111

3rd May 2015, 22:35

are you using reclock for wasapi exclusive? if so, I thought reclock only works in 32-bit mode?
There is something called the MPC Audio Renderer, it's based on WASAPI. It supports Shared Mode (send audio to the Windows mixer like normal) and Exclusive mode (bypass the mixer). MPC-HC's audio renderer is broken, MPC-BE however has it fixed and with config options. You can change it to Exclusive Mode + bit-perfect output. You can select it in the Audio options.

My only annoyance with MPC-BE is it keeps turning subtitles on, even though I use external LAV, XySubFilter and have LAV set to load Forced only. If MPC-HC had WASAPI Exclusive (to bypass the noise floor of the Mixer that somehow gets through to my receiver), I would definitively switch back. I've heard their working on it.

Edit: Ninjaed. :)

MS-DOS

3rd May 2015, 23:12

bined with bitstreaming, WASAPI Exclusive (for AAC/FLAC in anime, MPC-BE has a fixed Audio Renderer), 64 bit chain and the windowed overlay + present in advance setup, playback is amazing. Well done madshi, you have created an exceptional renderer.
Agreed. Since the release of 64 bit version I got pretty much everything I wanted from MadVR :)

Rendering is already mixed right now, with D3D9 shaders, OpenCL stuff (NNEDI3) and DirectCompute stuff (error diffusion).

Well then, do you have any plans on moving the shaders to another API like D3D11? If that's possible and useful for anything except eliminating the interop problem on AMD cards, of course.

Asmodian

4th May 2015, 00:10

Correct, and this is even done in 16bit+, while most GPUs apply the gamma ramps in 8bit, only, AFAIK.

I have noticed better quality (reduced banding) using madVR's emulation compared to the hardware LUTs. :)

baii

4th May 2015, 01:28

I have noticed better quality (reduced banding) using madVR's emulation compared to the hardware LUTs. :)
What hardware lut you referring to?

Sent from my 306SH

James Freeman

4th May 2015, 05:06

While Windows 7 Overlay mode does bypass the GPU ramps the option does still do something. Without the option madVR will load the ramps from the GPU and apply them with its own processing, emulating the GPU ramps. "disable GPU gamma ramps" disables this emulation so you need to specifically create a 3DLUT without gamma ramps to use with this option.

I do agree, it is great that when using Overlay "disable GPU gamma ramps" only applies to madVR. You can use only a 3DLUT for correction in madVR and still have basic correction for the rest of Windows.

Correct, and this is even done in 16bit+, while most GPUs apply the gamma ramps in 8bit, only, AFAIK.

This is great, I never noticed that when "disable calibration controls for this display" is used, madVR uses my windows gamma ramps but in 16bit+.

My 3DLUT includes in it a gamma ramp and LUT gamut correction, so the "disable GPU gamma ramps" does nothing when "calibrate this display.. external 3DLUT files" is selected because the 3DLUT bypasses my windows gamma ramps automatically.