madVR - high quality video renderer (GPU assisted)

[nevcairiel]

I wonder if thats really a NVIDIA bug. It seems a bit far-fetched to assume that the compiled kernels can be exchanged freely between 32 and 64-bit. Maybe madVR should just re-compute them if switching architecture.

[yuriks]

I have never actually ran 64-bit madVR on this machine. To me it seems like a code generation bug that only happens on the 32-bit driver userspace, and so compiling and caching the kernel on 64-bit works around it.

[nevcairiel]

I guess I misunderstood then. The kernel generated with the x64 version actually works properly in the 32-bit version then, but the one generated by the 32-bit version doesn't work in the 32-bit version?

Ok that does sound like a bug. :)

[huhn]

nvidia reproduced it too but they didn't fixed it in 352.63.
@SecurityBunny
i saw that back with 349.65 and added a note about this in the bug tracker. but it looks like it's a win10 only bug so i just leave it be and wait. 350.05 was working for me and i didn't tested 352.63 with chroma upscale yet.

[x7007]

Lol, funny, the issue I had with the video and the nvidia error was only happening with subtitles in potplayer and it happened because the special Pause Word Searching option... Can't believe how much CHAOS can subtitles do, even crashing the nvidia driver.

[Kirk Lazarus]

Hi guys,
AMD or NVIDIA cards are capable to output a RGB 4:4:4 10bit signal?

If yes, madVR is able to take advantage of the 10bit output?

many thanks

[mrbinky]

Since I installed the 64 bit version of madvr and MPC-HC (and 64 bit versions of LAV and other filters), MPC-HC has started crashing if I try to play more than on video in a row.

After the first video finishes, MPC-HC crashes just before it starts playing the second video in the folder. If I try to skip to the next video, it crashes immediately.

If I change the rendering engine to one of the others offered (besides MADVR), then it doesn't crash anymore.

This is new behavior, since updating to the 64 bit version.

[huhn]

Hi guys,
AMD or NVIDIA cards are capable to output a RGB 4:4:4 10bit signal?

If yes, madVR is able to take advantage of the 10bit output?

many thanks

madVR outputs 8 bit only.

maybe the next version will support 10 bit output.

[Anime Viewer]

Since I installed the 64 bit version of madvr and MPC-HC (and 64 bit versions of LAV and other filters), MPC-HC has started crashing if I try to play more than on video in a row.

After the first video finishes, MPC-HC crashes just before it starts playing the second video in the folder. If I try to skip to the next video, it crashes immediately.

If I change the rendering engine to one of the others offered (besides MADVR), then it doesn't crash anymore.

This is new behavior, since updating to the 64 bit version.

Is that with the "play next in folder" selected, or is it happening with videos you've set in your play list?

I used to have similar issues when using the "play next in folder" option selected in mpc-hc, but didn't have any problem doing the same but with mpc-be.

Have you tested with mpc-be x64 to see if you have the same problem with it?
http://sourceforge.net/projects/mpcbe/

If it works with mpc-be then it may be a mpc-hc problem not a madVR one.

[mrbinky]

Is that with the "play next in folder" selected, or is it happening with videos you've set in your play list?

I used to have similar issues when using the "play next in folder" option selected in mpc-hc, but didn't have any problem doing the same but with mpc-be.

Have you tested with mpc-be x64 to see if you have the same problem with it?
http://sourceforge.net/projects/mpcbe/

If it works with mpc-be then it may be a mpc-hc problem not a madVR one.
Just now installed MPC-BE 64, turned on MADVR, quit, then re-ran MPC-BE, played a video to the end, it stopped because I hadn't told it to play the next video in the folder, so I dragged another video onto the player window. It immediately crashed rather than playing the video.

Turned on enhanced renderer, tried the above, worked fine. Was able to play several videos in a row. Drag them onto the window, whatever. Never crashed once.


Turned on MADVR, started a video playing, dragged another video onto the window. Crashed immediately.

Went back to MPC-HC, tried the above, same result. Works with enchanced renderer, crashes with MADVR. MADVR will not allow me to play more than one video without closing MPC-HC or MPC-BE and re-starting it.

[Anime Viewer]

Just now installed MPC-BE 64, turned on MADVR, quit, then re-ran MPC-BE, played a video to the end, it stopped because I hadn't told it to play the next video in the folder, so I dragged another video onto the player window. It immediately crashed rather than playing the video.

Turned on enhanced renderer, tried the above, worked fine. Was able to play several videos in a row. Drag them onto the window, whatever. Never crashed once.

Turned on MADVR, started a video playing, dragged another video onto the window. Crashed immediately.

Went back to MPC-HC, tried the above, same result. Works with enchanced renderer, crashes with MADVR. MADVR will not allow me to play more than one video without closing MPC-HC or MPC-BE and re-starting it.

What up and down scalers do you have selected in madVR? (Have you tried other upscaling or downscaling options to see if one of the processing methods is related?) What do you have selected for dithering? (If you're using one of the Error Diffusion options have you tried switching to random or ordered and seen if the problem still exists?) Are you using NNEDI3 for anything (chroma upscaling or image doubling)? (If you're using NNEDI3 have you tried deleting the OpenCL registry key HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL to see if there is still the problem after it rebuilds it?)

[mrbinky]

What up and down scalers do you have selected in madVR? (Have you tried other upscaling or downscaling options to see if one of the processing methods is related?) What do you have selected for dithering? (If you're using one of the Error Diffusion options have you tried switching to random or ordered and seen if the problem still exists?) Are you using NNEDI3 for anything (chroma upscaling or image doubling)? (If you're using NNEDI3 have you tried deleting the OpenCL registry key HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL to see if there is still the problem after it rebuilds it?)
Sorry, I don't have time to try a bunch of different things. My setup used to work before I upgraded to x64. I did try deleting the opencl key, but it didn't help.

When I want videos to run without intervention, I switch to non MADVR, and it works fine. So, at least I have a work-around.
If I want better quality, and am willing to manually quit and re-run MPC-HC, I turn MADVR back on.

Hopefully, in the next version or so, this will be fixed. If not, I can live with it.

[Anime Viewer]

Sorry, I don't have time to try a bunch of different things.
Hopefully, in the next version or so, this will be fixed. If not, I can live with it.

Unless some is able to replicate your problem, and then further isolate what is connected with it (since you don't want to troubleshoot it further on your end) its unlikely that you'll be seeing a fix anytime soon.

[michkrol]

Just now installed MPC-BE 64, turned on MADVR, quit, then re-ran MPC-BE, played a video to the end, it stopped because I hadn't told it to play the next video in the folder, so I dragged another video onto the player window. It immediately crashed rather than playing the video.
(...)

Just to make sure - are you using the latest nightly build of MPC-HC?
Try version 1.7.8.162 (or higher when available) from https://nightly.mpc-hc.org/
It was a known problem just after the first x64 madVR release and has since been fixed inside MPC-HC.

[FireFreak111]

Some news on Windows 10 and the Nvidia drivers (352.63), in the driver you can actually change the Output color depth. The RGB, Range and Depth settings are all in the Change Resolution page. On one of my displays hooked up to a reciever via HDMI, 8bpc is the only option. On a monitor hooked directly by HDMI, 12bpc is an option. The display is 6 bit + FRC, which proves the option is just internal dithering or broken, but this raises the question of whether madVR would output the correct bit depth if a higher one is selected.

Also, NNEDI3 is broken right now in Windows 10 with the new driver, but that likely isn't a madVR issue. Everything else is working well, all the dithering line issues were fixed in 350.12, no problems with the new windowed path. I can't wait for the D3D11 presentation path too (D3D12???).

Interesting about the Win32 apps in the Windows store (in a sandboxed state), but I doubt madVR in its current state (DirectShow) would ever get in, unless it came prebundled with MPC-HC or MPC-BE.

[nevcairiel]

Some news on Windows 10 and the Nvidia drivers (352.63), in the driver you can actually change the Output color depth. The RGB, Range and Depth settings are all in the Change Resolution page. On one of my displays hooked up to a reciever via HDMI, 8bpc is the only option. On a monitor hooked directly by HDMI, 12bpc is an option. The display is 6 bit + FRC, which proves the option is just internal dithering or broken, but this raises the question of whether madVR would output the correct bit depth if a higher one is selected.

madVR always outputs 8-bit.

[STaRGaZeR]

But thats simply not how madVR is designed. Its designed to work against a fixed VSYNC, and use this VSYNC for perfect presentation. If it doesn't have a VSYNC to work with, it needs to implement a whole new logic.
And then the question is, whats there to even gain over a fixed VSYNC? The only single case would be true-VFR video, which is extremely uncommon as it is.

Precisely, but that's a limitation of madVR, not of the variable refresh monitors. You would need almost no logic with one of these. Maybe buffering a few frames to smooth out playback chain jitter, or to implement frame x-plication in the renderer instead of leaving the GPU/monitor do it, but that's it. Just present the frames as they come, or just after that jitter correction. There is no better situation for video playback than a variable refresh, because you're never ever going to get perfect sync between the monitor and everything else without dropping/repeating frames, frame interpolation or using something like Reclock.

It's clear why G-Sync and adaptive sync monitors right now suck for video playback, everything in the chain is assuming fixed refreshes in the monitor and adapting for that. If this changes, and it will change sooner or later, you can say goodbye to video stuttering forever.

[huhn]

Precisely, but that's a limitation of madVR, not of the variable refresh monitors. You would need almost no logic with one of these. Maybe buffering a few frames to smooth out playback chain jitter, or to implement frame x-plication in the renderer instead of leaving the GPU/monitor do it, but that's it. Just present the frames as they come, or just after that jitter correction. There is no better situation for video playback than a variable refresh, because you're never ever going to get perfect sync between the monitor and everything else without dropping/repeating frames, frame interpolation or using something like Reclock.
a cutom refresh rate get's you to a point you will never see a dropped or repeated frame.

It's clear why G-Sync and adaptive sync monitors right now suck for video playback, everything in the chain is assuming fixed refreshes in the monitor and adapting for that. If this changes, and it will change sooner or later, you can say goodbye to video stuttering forever.

what about audio sync?

just displaying all frames buy using the time stamps doesn't do the trick...

[kalston]

Precisely, but that's a limitation of madVR, not of the variable refresh monitors. You would need almost no logic with one of these. Maybe buffering a few frames to smooth out playback chain jitter, or to implement frame x-plication in the renderer instead of leaving the GPU/monitor do it, but that's it. Just present the frames as they come, or just after that jitter correction. There is no better situation for video playback than a variable refresh, because you're never ever going to get perfect sync between the monitor and everything else without dropping/repeating frames, frame interpolation or using something like Reclock.

It's clear why G-Sync and adaptive sync monitors right now suck for video playback, everything in the chain is assuming fixed refreshes in the monitor and adapting for that. If this changes, and it will change sooner or later, you can say goodbye to video stuttering forever.

I agree but I also think nev has a point when he says that madshi should be focusing on other things for now since gsync/freesync is only found in gaming monitors for the time being.

[nussman]

what about audio sync?

just displaying all frames buy using the time stamps doesn't do the trick...
Why not?
I think madVR is displaying frames by using time stamps and drops/repeates frames by "working against VSync"?

[huhn]

Why not?
I think madVR is displaying frames by using time stamps and drops/repeates frames by "working against VSync"?

the difference between audio and video clock is the issue.

[mrbinky]

Just to make sure - are you using the latest nightly build of MPC-HC?
Try version 1.7.8.162 (or higher when available) from https://nightly.mpc-hc.org/
It was a known problem just after the first x64 madVR release and has since been fixed inside MPC-HC.

Yes, I have been using version 162.

I also have the latest beta catalyst drivers, sapphire 270x. Latest windows 7. Chroma up-sampling with nned13, nne13 luma and chroma. Doesn't seem to matter if I turn them off. software decoding with latest 64bit lav filters, separate device for presentation and dxva, everything don't flush. don't know what other settings you want to know about.

I'm sure this will eventually get fixed. In the meantime, I'll just manually close mpc-hc before running another video. When my kids want to have a cartoon marathon, I'll turn madvr off first (they don't seem to even notice the difference, which kind of makes me wonder if this is really all worth it, given that my machine would be capable of playing videos without the 270x just fine without madvr and nned13...especially now that it's not working right anyway.)

[huhn]

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.

[Asmodian]

the difference between audio and video clock is the issue.

Use the audio clock as the source of time for when to present frames and ignore the video clock. :devil:

[Kirk Lazarus]

madVR outputs 8 bit only.

maybe the next version will support 10 bit output.

Ok but imagine that tomorrow Madshi release the new madVR with 10bit output .... NVIDIA or AMD cards are capable to output signal higher than 8bit ???

[e-t172]

Use the audio clock as the source of time for when to present frames and ignore the video clock. :devil:

Yes. This is probably the most interesting use of G-Sync or FreeSync for video playback. It basically solves all the clock issues, because the video clock can simply be slaved to the audio clock. No resampling, no fiddling with custom refresh rates, no dropped frames, no repeats. It "just works", just like a standalone set-top box player.

However, the problem with the current adaptive sync implementations is that you can't present frames in advance, and frames are presented immediately without waiting for any kind of event (like VSync), which means any jitter in the frame-flip code ends up in the final output.

Now, in steady-state operation the jitter is probably too small to be perceptible, however the real trouble happens when the system experiences a "hiccup" (e.g. the presentation thread gets starved for a few milliseconds due to system load) of more than a few milliseconds. It could be argued that such hiccups should not happen on a good system, but on the other hand, asserting that the timing will be spot-on all the way throughout a 2+ hour movie is a risky bet. That said, it would be interesting to test this and try to come up with actual data and evidence; maybe we're being overparanoid, and it would work just fine on most systems, especially if using a high-priority near-real-time scheduling priority for the presentation thread.

Ideally, the interface between the application and the adaptive sync implementation (which is DirectX in this case) should be improved to allow the presentation of multiple frames in advance while still allowing the timing of the individual frames to be customized, but that's unlikely to happen any time soon. That said, there were rumors some time ago about Windows Media Player in Windows 10 being able to use adaptive sync, so maybe they're coming up with some kind of API for that after all.

[huhn]

Ok but imagine that tomorrow Madshi release the new madVR with 10bit output .... NVIDIA or AMD cards are capable to output signal higher than 8bit ???

they can do this for years...
so yes they will be able to do something that's part of dx 10

[huhn]

Yes. This is probably the most interesting use of G-Sync or FreeSync for video playback. It basically solves all the clock issues, because the video clock can simply be slaved to the audio clock. No resampling, no fiddling with custom refresh rates, no dropped frames, no repeats. It "just works", just like a standalone set-top box player.

However, the problem with the current adaptive sync implementations is that you can't present frames in advance, and frames are presented immediately without waiting for any kind of event (like VSync), which means any jitter in the frame-flip code ends up in the final output.

Now, in steady-state operation the jitter is probably too small to be perceptible, however the real trouble happens when the system experiences a "hiccup" (e.g. the presentation thread gets starved for a few milliseconds due to system load) of more than a few milliseconds. It could be argued that such hiccups should not happen on a good system, but assuming the timing will be spot-on all the way throughout a 2+ hour movie is a risky bet. That said, it would be interesting to test this and try to come up with actual data and evidence; maybe we're being overparanoid, and it would work just fine on most systems, especially if using a high-priority near-real-time scheduling priority for the presentation thread.

Ideally, the interface between the application and the adaptive sync implementation (which is DirectX in this case) should be improved to allow the presentation of multiple frames in advance while still allowing the timing of the individual frames to be customized, but that's unlikely to happen any time soon. That said, there were rumors some time ago about Windows Media Player in Windows 10 being able to use adaptive sync, so maybe they're coming up with some kind of API for that after all.

no it doesn't because it doesn't work with low frame rates.
what is needed 40 plus?

[e-t172]

I don't see the issue with low frame rates. If the screen only supports 40+Hz, and you have a 24p stream, the solution is trivial: just present each frame twice to get to 48p.

[Asmodian]

However, the problem with the current adaptive sync implementations is that you can't present frames in advance, and frames are presented immediately without waiting for any kind of event (like VSync), which means any jitter in the frame-flip code ends up in the final output.

I am not sure it means anything in this context but the present buffer stays full (according to ctrl+j) even when using G-sync if the render times are below the movie's frame rate. This wouldn't help jitter but maybe madVR could keep the same render queue.

no it doesn't because it doesn't work with low frame rates.
what is needed 40 plus?

G-sync handles this for you so you can completely ignore handling the low frame rates if you want to. All G-sync monitors currently support 30-144 Hz physically but can display 0-144 Hz well. All currently available FreeSync monitors (AMD's version) need 40 Hz minimum except two which need a minimum of 48 Hz. Both of those are 48-75 Hz (not very useful) and are 21:9 displays so I don't think we need to worry about them. FreeSync doesn't handle below the VRR well, yet.

If madshi did decide to support a variable refresh rate mode leaving the outside of the VRR behavior to the drivers would be fine. Of course a simple double if below X Hz feature would be good too. :p

[madshi]

I have monitors which darken (lower gamma) when the refresh rate is overclocked beyond 60Hz as written here: http://www.gamersnexus.net/guides/1674-overclock-monitor-higher-refresh-rate

@madshi I'm curious, does it make sense to allow for madVR to use different 3DLUT profiles that have been generated from calibrations at different refresh rates in conjunction with the refresh rate changer?

If so, I'll be able to match refresh rate and frame rate on all files.
At some point I'm going to allow profiles for "device" settings, too. That should solve the problem for you. But it's not very high priority at the moment.

I'm getting video freezes when using MPC-HC 1.7.8 and MadVR latest build to scale to UHD. Video will play to a random point then freeze, but the audio continues to play. I try to engage task manager but all I have after a control+alt+delete is a blank screen. I try to use the control+alt+delete to shutdown the system but I get the same blank screen & no shutdown. I have to do a hard restart with the power switch.

[...]

My *guess* is that I'm overpowering the GPU on the R9 280x by getting everything up to 3820x2160.
Possible. Try with less demanding settings. If that runs through fine then your guess is probably right.

I don't know if this issue is related to madVR or MPC-HC but the "Save Image" function of MPC-HC is broken since 0.87.16, even with the new x64 releases.

I got the following error message: "GetDIB failed, hr=80004005".
Could be a bug in madVR. Please upload your madVR settings (see "settings.bin" in your madVR folder, if madVR is allowed to write to its own folder; otherwise export HKEY_CURRENT_USER\Software\madshi\madVR\Settings") and also please post a screenshot of the madVR debug OSD (Ctrl+J) from a situation where this problem occurs, so that I can reproduce with a similar video size / display resolution setup.

Please don't attach the file to this forum, upload somewhere else and just post the link here. Thanks.

I am using madVR with PotPlayer on Windows 8.1 on my Laptop

It all works very well, but one weird thing I've notice is that my laptops fan speeds up significantly when I pause a video. Then when I press play the fan will eventually slow down again.

Anyone have any idea what's causing this?
Yes, it's mostly madVR's fault, it will need a new madVR build to get fixed, and also a new PotPlayer version. And it's going to take a while until I get there. For now, you'll have to live with it, unfortunately.

Has the small change - to not upscale 1916x1076 and 1912x1072 to 1920x1080 (perhaps optionally), been implemented ?
No, not yet.

You should actually watch a movie and judge based on the final drop count. The estimate given by madVR is nothing but that, a estimate, it has no guarantees of perfect accuracy.
Exactly. Watch multiple long movies, reset the statistics a couple seconds after movie play back start (sometimes a frame drop occurs right when starting the movie) and check the OSD after each movie has run through.

could you please allow madhccctrl to recognize the "windows minimize" message?
I'm not sure if I can enable minimizing without allowing maximizing, resizing etc. I don't feel like spending time for that at the moment, and then having to deal with all the consequences like maximizing, resizing etc, or trying to block what should not be done etc.

Its interesting seeing the results of NNEDI3 testing that is currently going on [...], and how different shader codes (optimizations) seem to make a significant difference at higher settings depending on what code is being used (Perfer Scalar, Perfer Vector, or Avoid Branches).

madashi: Out of curiosity which style of NNEDI3 is used with madVR currently (any of these, or something different)? Don't know how important NNEDI3 optimization in madVR is on your list of priorities, but something similar might be worth testing.
From what I've seen, most of the modifications worked worse than the original, and those that gave an improvement only gave a relatively small improvement and only for some GPUs and only in some cases. So at this point I'm not going to bother. Maybe later.

NNEDI3 still causing issues with potplayer , with subtitles or without. with subtitles it causing High Cpu Usage in pause mode randomly until I playback again and it lowers to 3% .
See above.

I've been testing some settings in madvr and I found that when I use the windowed fullscreen mode(new path), I get average rendering times around ~8.00 ms and present 0.14 ms, when I switch to fullscreen exclusive mode(old path) I get average rendering time ~16.00 ms and present 0.01 ms, it looks kinda strange to me
Seems strange to me, too. Rendering times are roughly comparable on my PC.

I cannot possibly get NNEDI3 to work properly on my r290x in any driver besides 13.12, which offers flawless playback, for some very odd reason.
Then why don't you simply stay on 13.12, as many other users are doing, too?

This issue exists in all windows 10 nvidia dx12 display driver versions. (349.65, 349.90, & 352.63)
I don't have Windows 10 installed yet, so anything that only reproduces on Windows 10 I can't help with, for now.

AMD or NVIDIA cards are capable to output a RGB 4:4:4 10bit signal?
Yes. Maybe not for 4Kp60, though.

Since I installed the 64 bit version of madvr and MPC-HC (and 64 bit versions of LAV and other filters), MPC-HC has started crashing if I try to play more than on video in a row.
Are you running v0.87.21? It contains an important bug fix over v0.87.20 for x64 stability. Also, the next build will contain some more stability fixes for x64 stability.

maybe the next version will support 10 bit output.
Yes, it will.

On a monitor hooked directly by HDMI, 12bpc is an option. The display is 6 bit + FRC, which proves the option is just internal dithering or broken, but this raises the question of whether madVR would output the correct bit depth if a higher one is selected.
Which native bitdepth your display's panel has, and which bitdepth your display accepts as input formats are 2 different things. It's possible that your display could accept 12bit, then internally dither it down to whatever your panel natively supports. I don't really know. Which bitdepth to send to your display is something your eyes will have to be the judge of.

Interesting about the Win32 apps in the Windows store (in a sandboxed state), but I doubt madVR in its current state (DirectShow) would ever get in, unless it came prebundled with MPC-HC or MPC-BE.
I've zero interest in Windows store.

Precisely, but that's a limitation of madVR, not of the variable refresh monitors. You would need almost no logic with one of these. Maybe buffering a few frames to smooth out playback chain jitter, or to implement frame x-plication in the renderer instead of leaving the GPU/monitor do it, but that's it. Just present the frames as they come, or just after that jitter correction.
If I just presented the frames as they come, I would present them at the speed of the decoder. Meaning with e.g. Blu-Rays, decoded on a modern PC, probably playback would run at several hundred fps. Is that really what you want? :p

It seems to me you don't understand the basic DirectShow renderer concept. Let me explain: Every DirectShow graph has a master clock (usually provided by the audio renderer). And every renderer (audio and video etc) has to obey the master clock. Each "sample" is timestamped. And each renderer has to "present" each samples at the exact moment when the master clock matches the sample's timestamp. Unfortunately Windows is not a real-time operating system. That means there's no guarantee that any sort of software will get CPU time at any specific time. If madVR were to wait for the master clock to exactly reach the timestamps of the "next" to-be-presented sample, and then present the video frame at that moment in time, this would sometimes work well, and sometimes it wouldn't. Imagine the anti-virus software has suddenly decided to need to CPU for some heavy calculations. And at the same time the browser sitting in the background updates all the tabs, and some other stuff goes on as well. It can happen that madVR doesn't get CPU time for a couple of milliseconds. And ooops, as quickly as that madVR might miss the right time to present the next frame. You see the problem?

With games it's a whole different situation: There you render a frame, which takes time, then you present, and you want the rendered frame to be shown on the screen as quickly as possible. Video rendering is *totally* different. You do want rendering to happen as quickly as possible - but not presentation! Instead you want frames to be presented at very specific timestamps. And to make that work as reliably as possible, you want to present several frames in advance. G-Sync/FreeSync could be useful for that, but only if they allowed me to send them a couple of video frames in advance, with a specific timestamp tied to each video frame at which G-Sync/FreeSync should switch to them. This is not what any game needs, so I have my doubts that G-Sync/FreeSync support that kind of feature.

Ultimately, madshi decides of course if he thinks its worth trying to bother with it in madVR, but personally, I would rather have him work on so many other features. :)
Fully agreed.

Btw, has anybody heard of any *TVs* or *projectors* supporting G-Sync of FreeSync? I've no heard of any announced. That is very very important, because basically if G-Sync/FreeSync is just going to be used for computer monitors, that very much limits the use, because madVR's primary use is for TVs/projectors, not for computer monitors. Of course madVR wants to do its best for computer monitors, too, but at this point I'm not going to halt all other development, just to implement something which is only going to benefit computer monitors.

[Asmodian]

Unfortunately Windows is not a real-time operating system. That means there's no guarantee that any sort of software will get CPU time at any specific time. If madVR were to wait for the master clock to exactly reach the timestamps of the "next" to-be-presented sample, and then present the video frame at that moment in time, this would sometimes work well, and sometimes it wouldn't. Imagine the anti-virus software has suddenly decided to need to CPU for some heavy calculations. And at the same time the browser sitting in the background updates all the tabs, and some other stuff goes on as well. It can happen that madVR doesn't get CPU time for a couple of milliseconds. And ooops, as quickly as that madVR might miss the right time to present the next frame. You see the problem?

I don't really see a problem. The entire point of a variable refresh display is that you cannot miss the right time to present the next frame. There will be some jitter in the timing if sometimes a frame is presented one or two milliseconds late but the next frame would still be on time and I doubt this would be noticeable. Certainly it would be nothing like missing a V-sync interval.

I don't see a significant difference between each renderer "presenting" each sample at the exact moment when the master clock matches the sample's timestamp and telling the driver to present a frame at a specific time; is the driver that much better at being realtime? Also games actually have the same issue too, they need to meter the frames, especially with SLI, or you get "micro stutter". Both GPU makers have done a lot in their drivers to improve this frame metering for games over the past few years. You need the frame display times to match the CPU simulation times (game engine) or motion isn't smooth.

Btw, has anybody heard of any *TVs* or *projectors* supporting G-Sync of FreeSync? I've no heard of any announced. That is very very important, because basically if G-Sync/FreeSync is just going to be used for computer monitors, that very much limits the use, because madVR's primary use is for TVs/projectors, not for computer monitors. Of course madVR wants to do its best for computer monitors, too, but at this point I'm not going to halt all other development, just to implement something which is only going to benefit computer monitors.

No TVs yet but variable refresh has only now started to be available. I believe (and hope) some form of VRR support will make it into most displays at some, probably distant, point in the future. :p

Of course work on what seems interesting and beneficial to you. Variable refresh rate is huge to me so I cannot stop hoping for a video renderer to support it. :)

[e-t172]

I don't really see a problem. The entire point of a variable refresh display is that you cannot miss the right time to present the next frame. There will be some jitter in the timing if sometimes a frame is presented one or two milliseconds late but the next frame would still be on time and I doubt this would be noticeable. Certainly it would be nothing like missing a V-sync interval.

As I explained, it's all about quantity. It's possible that the jitter from the OS scheduling is not bad enough to be noticeable (especially when using OS-provided facilities for "near-real-time" scheduling), but we'll never know for sure until someone tries it. We need more data.

I don't see a significant difference between each renderer "presenting" each sample at the exact moment when the master clock matches the sample's timestamp and telling the driver to present a frame at a specific time; is the driver that much better at being realtime?

The way a GPU works with traditional refresh rate operation is that a frame is sent to the output every VSync interval from the framebuffer. This is not done by the driver but entirely in hardware using a purely hardware clock (the video clock); the OS doesn't even know that happened until the GPU sends a VSync event to the system. Because this is driven by a hardware clock on dedicated hardware, the jitter is vanishingly small. That's not the case with variable refresh rate, in which the timing of frames is not decided directly by the GPU: it's decided by software, and there is no video clock.

No TVs yet but variable refresh has only now started to be available. I believe (and hope) some form of VRR support will make it into most displays at some, probably distant, point in the future. :p

Yeah. The problem is, VRR on TVs/projectors seems like it would only fulfill a niche use case. The only way I can see TV manufacturers getting interested in VRR is if the next generation of gaming consoles make use of it, and that's a long ways off.

[madshi]

I don't really see a problem. The entire point of a variable refresh display is that you cannot miss the right time to present the next frame. There will be some jitter in the timing if sometimes a frame is presented one or two milliseconds late but the next frame would still be on time and I doubt this would be noticeable. Certainly it would be nothing like missing a V-sync interval.
And what happens if the timing is off by 5ms? Or by 10ms? Or even 16ms? You know, the default timer interval in Windows is 16ms. So it shouldn't come as a surprise if in CPU stress situations a video renderer might sometimes not get any CPU time for 16ms or even more. 1000/60fps = 16.67ms.

I don't see a significant difference between each renderer "presenting" each sample at the exact moment when the master clock matches the sample's timestamp and telling the driver to present a frame at a specific time; is the driver that much better at being realtime?
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.

No TVs yet but variable refresh has only now started to be available. I believe (and hope) some form of VRR support will make it into most displays at some, probably distant, point in the future.
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?

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).

[STaRGaZeR]

If I just presented the frames as they come, I would present them at the speed of the decoder. Meaning with e.g. Blu-Rays, decoded on a modern PC, probably playback would run at several hundred fps. Is that really what you want? :p

It seems to me you don't understand the basic DirectShow renderer concept. Let me explain: Every DirectShow graph has a master clock (usually provided by the audio renderer). And every renderer (audio and video etc) has to obey the master clock. Each "sample" is timestamped. And each renderer has to "present" each samples at the exact moment when the master clock matches the sample's timestamp. Unfortunately Windows is not a real-time operating system. That means there's no guarantee that any sort of software will get CPU time at any specific time. If madVR were to wait for the master clock to exactly reach the timestamps of the "next" to-be-presented sample, and then present the video frame at that moment in time, this would sometimes work well, and sometimes it wouldn't. Imagine the anti-virus software has suddenly decided to need to CPU for some heavy calculations. And at the same time the browser sitting in the background updates all the tabs, and some other stuff goes on as well. It can happen that madVR doesn't get CPU time for a couple of milliseconds. And ooops, as quickly as that madVR might miss the right time to present the next frame. You see the problem?

With games it's a whole different situation: There you render a frame, which takes time, then you present, and you want the rendered frame to be shown on the screen as quickly as possible. Video rendering is *totally* different. You do want rendering to happen as quickly as possible - but not presentation! Instead you want frames to be presented at very specific timestamps. And to make that work as reliably as possible, you want to present several frames in advance. G-Sync/FreeSync could be useful for that, but only if they allowed me to send them a couple of video frames in advance, with a specific timestamp tied to each video frame at which G-Sync/FreeSync should switch to them. This is not what any game needs, so I have my doubts that G-Sync/FreeSync support that kind of feature.

When I say "as they come", I mean "as the timestamps tell you to display them", obviously.

Your post reads as if Windows not being a real-time OS doesn't affect all fixed refresh rate monitors right now in exactly the same way. It does :devil:. Your current logic, or any future logic you may implement, suffers from it. You have no way around other programs stealing your CPU time. This point really is moot. Also a frame buffer (or several buffers like you have right now for the exact same purpose) would fix most of the playback chain jitter.

REAL advantages of variable refresh displays for video playback are:


Monitor sync: no need for it. I've seen people in this thread freak out about 1 frame repeat every >5 hours, which is absurd. But even this would be gone. It'd be as good as our non-real-time OSes allow it to be. Certainly miles better than missing a VSync interval.
Content from different locations. Right now is a royal pain in the ass to properly configure several refresh rates for each video frame rate source (24/25/30/48...). And even more pain in the ass to change between them each time you open a video, even if the player does it for you.
VFR content.
All this without messing with the audio (master) clock, with all its known implications.

I guess we won't see any of this until HDMI supports variable refresh displays, just like we didn't see an x64 version until people realized there was a new decoder which clearly benefited from it (H.265, but H.264 already did a lot earlier, nobody cared). There is hope Microsoft is faster than you on this one :p

EDIT: ninja'ed!

[madshi]

Your post reads as if Windows not being a real-time OS doesn't affect all fixed refresh rate monitors right now in exactly the same way. It does :devil:. Your current logic, or any future logic you may implement, suffers from it. You have no way around other programs stealing your CPU time. This point really is moot.
Sorry, but totally incorrect. You may want to do some research into VSync hardware interrupts. Which to my best knowledge are used in Direct3D FSE mode to switch backbuffers. Try this: Let madVR run in FSE mode, use a low refresh rate, turn the GPU queue and number of prepresented frames us as high as possible. Then let playback run, then suspend the madVR process (not allowing any CPU to be used by madVR). You should notice that video playback still continue to run for as long as the number of prepresented frames allows. 16 24p frames = 667.3ms. So basically in FSE mode with 16 prepresented frames madVR will produce smooth playback even if madVR doesn't get any CPU time for more than half a second (which is an eternity).

[Barnahadnagy]

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.

[e-t172]

Your post reads as if Windows not being a real-time OS doesn't affect all fixed refresh rate monitors right now in exactly the same way. It does :devil:. Your current logic, or any future logic you may implement, suffers from it. You have no way around other programs stealing your CPU time. This point really is moot. Also a frame buffer (or several buffers like you have right now for the exact same purpose) would fix most of the playback chain jitter.

I don't think you understand the problem. In a fixed refresh rate system, the framebuffer is in hardware and is read by a dedicated hardware output chip driven by a purely hardware clock. That basically means you can have as much software jitter as you want as long as you're not missing an entire VSync interval. In other words, in a fixed refresh rate system, as long as your presentation thread (or the GPU driver thread that does the actual framebuffer flip) is not delayed by more than 16ms (1/60Hz), the delays don't make any difference: the frames will be presented according to the refresh rate with perfect timing accuracy, because it's a hardware clock. Audio works the same way: there is a fixed-size buffer, and as long as you can provide new data before the buffer runs out, you're good, because there is a hardware audio clock that takes care of properly timing each individual sample from the buffer.

In practice, that means that your actual display interval will look like a perfect 16.666, 16.666, 16.666... the hardware clock guarantees that.

With variable refresh rate, current APIs like DirectX don't have any way of specifying frame timing in advance (said another way, there is no way to schedule or defer frames). Therefore, it is impossible to make use of the hardware clock. Instead, the clock has to be implemented in software by the video renderer through the timing of presentation calls. There is no way to implement a perfect clock in software in a non-realtime OS such as Windows, because the OS doesn't make any hard guarantees as to when your thread will run. Therefore, you will get at least some amount of output jitter. How much jitter exactly is an open question, and likely depends on the individual system (especially system load and cleanliness of various drivers).

With a software clock, you could get something like 16.521, 16.852, 16.235... which is probably fine and I guess would not be noticeable. However, if you end up with something like 15.121, 14.852, 18.321, 17.751, then maybe that would be noticeable and would result in non-smooth video. How bad would it be? It's unclear. Is it possible to alleviate this by using (or abusing) some Windows scheduler features for near-real-time scheduling (such as the Multimedia scheduler)? Again, unclear. We need to try it to be sure.

There are interesting parallels to be made by looking at the world of Pro Audio software, which also needs low latencies (<10 ms) for correct operation. There was a recent presentation (http://channel9.msdn.com/Events/WinHEC/2015/WHT202) from Microsoft about this regarding their goals in Windows 10. If that is of any indication regarding low-latency scheduling in Windows 10, then it looks like ~5 ms jitter might be achievable. 1 ms and less looks like it's not going to be easy. I suspect video playback driven by a software clock requires even lower latencies than Pro Audio. At least in Pro Audio you still have a buffer of a few milliseconds, but with variable refresh rate even that is gone, and your margin of error is very tight.

Try this: Let madVR run in FSE mode, use a low refresh rate, turn the GPU queue and number of prepresented frames us as high as possible. Then let playback run, then suspend the madVR process (not allowing any CPU to be used by madVR). You should notice that video playback still continue to run for as long as the number of prepresented frames allows. 16 24p frames = 667.3ms. So basically in FSE mode with 16 prepresented frames madVR will produce smooth playback even if madVR doesn't get any CPU time for more than half a second (which is an eternity).

Actually, from the performance analysis I did a while back using WPA/Xperf and the like, it looks like (at least on nVidia) the actual framebuffer flip is done by an nVidia driver thread sitting in the process itself, which probably means freezing the process would immediately freeze the video as well. Of course that's somewhat disappointing, as it's obviously better to do this stuff in hardware precisely to prevent this, but it seems like nVidia doesn't care that much. Though I guess it's possible the nVidia thread is seen as a "special snowflake" to the Windows scheduler in terms of priority.

Of course that doesn't invalidate your argument at all, I'm just nitpicking here.

[madshi]

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.
Agreed. Good first post... :)

I don't think you understand the problem. In a fixed refresh rate system, the framebuffer is in hardware and is read by a dedicated hardware output chip driven by a purely hardware clock. That basically means you can have as much software jitter as you want as long as you're not missing an entire VSync interval. In other words, in a fixed refresh rate system, as long as your presentation thread (or the GPU driver thread that does the actual framebuffer flip) is not delayed by more than 16ms (1/60Hz), the delays don't make any difference: the frames will be presented according to the refresh rate with perfect timing accuracy, because it's a hardware clock. Audio works the same way: there is a fixed-size buffer, and as long as you can provide new data before the buffer runs out, you're good, because there is a hardware audio clock that takes care of properly timing each individual sample from the buffer.

In practice, that means that your actual display interval will look like a perfect 16.666, 16.666, 16.666... the hardware clock guarantees that.

With variable refresh rate, current APIs like DirectX don't have any way of specifying frame timing in advance (said another way, there is no way to schedule or defer frames). Therefore, it is impossible to make use of the hardware clock. Instead, the clock has to be implemented in software by the video renderer through the timing of presentation calls. There is no way to implement a perfect clock in software in a non-realtime OS such as Windows, because the OS doesn't make any hard guarantees as to when your thread will run. Therefore, you will get at least some amount of output jitter. How much jitter exactly is an open question, and likely depends on the individual system (especially system load and cleanliness of various drivers).

With a software clock, you could get something like 16.521, 16.852, 16.235... which is probably fine and I guess would not be noticeable. However, if you end up with something like 15.121, 14.852, 18.321, 17.751, then maybe that would be noticeable and would result in non-smooth video. How bad would it be? It's unclear. Is it possible to alleviate this by using (or abusing) some Windows scheduler features for near-real-time scheduling (such as the Multimedia scheduler)? Again, unclear. We need to try it to be sure.
Good explanation.

Actually, from the performance analysis I did a while back using WPA/Xperf and the like, it looks like (at least on nVidia) the actual framebuffer flip is done by an nVidia driver thread sitting in the process itself, which probably means freezing the process would immediately freeze the video as well. Of course that's somewhat disappointing, as it's obviously better to do this stuff in hardware precisely to prevent this, but it seems like nVidia doesn't care that much. Though I guess it's possible the nVidia thread is seen as a "special snowflake" to the Windows scheduler in terms of priority.
Hmmmm... If true this would truely be disappointing. I do somewhat wonder, though: The whole Direct3D presentation model is defined by Microsoft and all 3 GPU implementations behave *exactly* identical in some very weird details, which IMHO make it rather probable that large parts of the presentation logic are implemented in Windows rather than in the GPU driver.

Just as an example: In the Direct3D11 DXGI "Present" call you can define a "delay" value, and this parameter behaves very weird in Windows 8.1, actually it's behaviour partially differs from the documentation. But the behaviour is exactly identical with all AMD, NVidia and Intel. How can that be the case if it all happens in a GPU specific thread running in the media player process?

[madshi]

Actually, from the performance analysis I did a while back using WPA/Xperf and the like, it looks like (at least on nVidia) the actual framebuffer flip is done by an nVidia driver thread sitting in the process itself, which probably means freezing the process would immediately freeze the video as well. Of course that's somewhat disappointing, as it's obviously better to do this stuff in hardware precisely to prevent this, but it seems like nVidia doesn't care that much. Though I guess it's possible the nVidia thread is seen as a "special snowflake" to the Windows scheduler in terms of priority.
I've just tested this on Windows 8.1 x64 with the latest madVR build (work in progress) with its new D3D11 presentation path: With 16 prepresented frames, if I suspend the whole MPC-HC process (using process explorer), video playback still continues to run smoothly for about half a second. If I disable "present several frames in advance", video playback freezes instantly if I suspend the whole MPC-HC process.

Q.E.D.

[e-t172]

Very well then. This was just a vague impression of mine as I was looking at the traces, I wasn't sure at all (especially since I have very limited knowledge about graphics programming in general). Glad that you cleared it up, that's actually good news :)

In addition, I think I wasn't being accurate when I was referring to an "nVidia driver thread", I think it actually was a DirectX thread that (judging from its stack trace) was calling into the nVidia driver at the time I was looking. Anyway, doesn't matter now.

[madshi]

Yep, good news indeed. I think I had done a similar test many months (years?) ago with D3D9 FSE with similar results, that's why I was pretty sure about it.

BTW, I've just tested the "new windowed mode" used by madVR, and it appears to have a similar effect - although due to different reasons: Basically the "new windowed mode" passes the frames to DWM/Aero, so it doesn't matter if you freeze MPC-HC, as long as you don't freeze DWM/Aero. But it's definitely not as reliable as FSE mode. For me FSE has always been dead reliable. I still believe it's based on VSync hardware interrupt backbuffer switching. At least it behaves as if it were, in my experience...

[kalston]

I don't know how it works but I find the overlay mode to be extremely reliable too, very similar performance to FSE on my rig (which is pretty nice since I run with Aero disabled and it doesn't trigger G-Sync when I enter fullscreen). It's not exclusive like FSE though of course, but I have no applications susceptible of disturbing playback with pop ups so it gets the job done for me.

[Qaq]

Has the small change - to not upscale 1916x1076 and 1912x1072 to 1920x1080 (perhaps optionally), been implemented ?That's the job of the media player. madVR only does what it's told by the player.You mean "players"? Cause it seems its simpler to fix in one renderer than in all players.

[ADude]

Is there a way to use the Profiles to choose no image upscaling at all (in some cases) ? Just bypass it altogether ?

[huhn]

You mean "players"? Cause it seems its simpler to fix in one renderer than in all players.

but player can do this already.

and madshi kind of saying it is planned too.

[huhn]

Is there a way to use the Profiles to choose no image upscaling at all (in some cases) ? Just bypass it altogether ?

no just set mpc-hc to video frame -> normal size.
you can most likely set a hot key for this and even map it to a remote.

[Qaq]

but player can do this already.
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.
and madshi kind of saying it is planned too.
Really? I only saw "No, not yet".

[ADude]

no just set mpc-hc to video frame -> normal size.
you can most likely set a hot key for this and even map it to a remote.

This requires me to run MediaInfo on every video (is it 1076 or 1080 ?), as well as press the remote button.

[huhn]

This requires me to run MediaInfo on every video (is it 1076 or 1080 ?), as well as press the remote button.

doesn't matter if the source is 1080 or 1076 you can just use normal for both. doesn't make any difference on a 1080p screen.