madVR - high quality video renderer (GPU assisted)

[madshi]

:( Can you create a freeze report, please? Press Ctrl+Alt+Shift+Break while the freeze is occurring. A couple seconds later there should be a freeze report on your harddisk.

Edit: Nevermind, was able to reproduce it here.

[vomanci]

Latest MadVR and MPC-HC, no image when windowed if DXVA downscaling is selected. If i go fullscreen, the image goes fastforward until it cathes up to the sound. If i change upscaling algo. , no problems. Tried other DXVA related trade options but no effect.
Windows 8.1, nVidia gtx650

[madshi]

Latest MadVR and MPC-HC, no image when windowed if DXVA downscaling is selected. If i go fullscreen, the image goes fastforward until it cathes up to the sound. If i change upscaling algo. , no problems. Tried other DXVA related trade options but no effect.
Windows 8.1, nVidia gtx650
Can't reproduce that here. Can you please create a debug log and zip & upload it somewhere (don't attach it to the forum, please)? Thanks!

[vomanci]

Log file https://www.sendspace.com/file/mwqyue

[huhn]

so it would seem , perhaps its me using NEEDI64 for chroma upscaling + image doubling set to 16 for all..hmmm..anyone can confirm this?

yes. you have to render more than 2 times the frames compared to 24 hz.

a what? you just have to click the attachment itll autolink, its currently showing as pending approval
and that's why i can't see it.
whys that so?

YADF is not the best deinterlacer it still pretty good as a software deinterlacer, it needs pretty beefy CPU for 1080i and you can't use madVR IVTC anymore.

[madshi]

Log file https://www.sendspace.com/file/mwqyue
Thanks. Hmmm... This is a strange format source with 1076 pixels height. Does the same problem occur with a normal Blu-Ray, too?

[vomanci]

Tried 4 different files with different sizes 720->1080, all same problems. If the player windows is smaller then the movie resolution (downscaled), the image is black. Sound goes on thou.

[madshi]

Do you have a "settings.bin" in your madVR folder (only if madVR can write to the folder)? If so, could you please upload that for me? Otherwise please export the madVR settings branch in the registry (HKEY_CURRENT_USER\Software\madshi\madVR\Settings). Thanks!

[vomanci]

settings.binhttps://www.sendspace.com/file/h70l3l

[madshi]

Thanks, with your settings I can reproduce the problem... :)

[sexus]

yes. you have to render more than 2 times the frames compared to 24 hz.


and that's why i can't see it.


YADF is not the best deinterlacer it still pretty good as a software deinterlacer, it needs pretty beefy CPU for 1080i and you can't use madVR IVTC anymore.

i see so apparently even a TITAN gtx ocd and unlocked isnt enough for NEEDI 50 fps , ok


and about deinterlacing , well so i guess we gotta bump up the gpu queue to 5 then according to you , to keep everything running , right?

[huhn]

i see so apparently even a TITAN gtx ocd and unlocked isnt enough for NEEDI 50 fps , ok


and about deinterlacing , well so i guess we gotta bump up the gpu queue to 5 then according to you , to keep everything running , right?

with my little testing and my system, yes 5 was save for me.

[baii]

If you mean the hard disk will have high read activity for a few sec, that happen before .18. Was using potplayer.

Sent from my 306SH

[huhn]

If you mean the hard disk will have high read activity for a few sec, that happen before .18. Was using potplayer.

Sent from my 306SH

what?

[flashmozzg]

I updated my madVR and noticed a lot of options in trade quality for performance checked (from top all the way to don't render if fade in/out). Do they have any noticeable impact on picture quality? What options are safest to have enabled and what my cause visible "artifacts"?

P.S. went from .11 to .18, render times went down noticeably (like x2 in some cases). But sometimes if I go fullscren the screen stays black for very long time (I didn't check if it worked in the end because I just went windowed and when full screen again and it was fine). I'm on 8.1 x64
EDIT: Checked render times - on 1080p generic 24fps video I had 16-18ms before. Now it's ~2.5ms. WOW. Probably something wasn't set up right before. (I have R9 290 btw).

[TheShadowRunner]

Hi mashi, long time no see.
Sadly I come with bad news: v87.18 freezes on fastforward / seek. Have to kill the player process manually to get out of it.
Here's a log:
http://videoff7.free.fr/madVRv0.87.18_freeze.zip
No issue whatsoever with v87.17.

[ryrynz]

I updated my madVR and noticed a lot of options in trade quality for performance checked (from top all the way to don't render if fade in/out). Do they have any noticeable impact on picture quality? What options are safest to have enabled and what my cause visible "artifacts"?


They won't obviously affect quality, feel free to untick and compare you'll see a reasonable difference in rendering time with them enabled and given the trade off it's worthwhile for many people to just keep the defaults.


P.S. went from .11 to .18, render times went down noticeably (like x2 in some cases). But sometimes if I go fullscreen the screen stays black for very long time (I didn't check if it worked in the end because I just went windowed and when full screen again and it was fine). I'm on 8.1 x64

Are you using Full screen exclusive mode? Try using Windowed mode, also update your graphics drivers. Are you switching refresh rates on fullscreen? Play with the options.

[sexus]

I updated my madVR and noticed a lot of options in trade quality for performance checked (from top all the way to don't render if fade in/out). Do they have any noticeable impact on picture quality? What options are safest to have enabled and what my cause visible "artifacts"?

P.S. went from .11 to .18, render times went down noticeably (like x2 in some cases). But sometimes if I go fullscren the screen stays black for very long time (I didn't check if it worked in the end because I just went windowed and when full screen again and it was fine). I'm on 8.1 x64
EDIT: Checked render times - on 1080p generic 24fps video I had 16-18ms before. Now it's ~2.5ms. WOW. Probably something wasn't set up right before. (I have R9 290 btw).

what how do you mean render times went down to 2.5 ms , do you mean render or present , theres a big difference, hell a screenshot would be best to show us by enablign madvr overlay info with ctrl+j

[huhn]

I updated my madVR and noticed a lot of options in trade quality for performance checked (from top all the way to don't render if fade in/out). Do they have any noticeable impact on picture quality? What options are safest to have enabled and what my cause visible "artifacts"?

P.S. went from .11 to .18, render times went down noticeably (like x2 in some cases). But sometimes if I go fullscren the screen stays black for very long time (I didn't check if it worked in the end because I just went windowed and when full screen again and it was fine). I'm on 8.1 x64
EDIT: Checked render times - on 1080p generic 24fps video I had 16-18ms before. Now it's ~2.5ms. WOW. Probably something wasn't set up right before. (I have R9 290 btw).

have you checked powerstates? rendertiems are unreliable.
as far as i know there are no serious speed optimization if that's even possible.

[flashmozzg]

what how do you mean render times went down to 2.5 ms , do you mean render or present , theres a big difference, hell a screenshot would be best to show us by enablign madvr overlay info with ctrl+j

I wasn't able to make a screenshot in fullscreen mode but made in windowed (render times should be lower in fullscreen anyway because it doesn't need to upscale/downscale)
http://i.imgur.com/PvuPr96.jpg
It might be a bug in recent madVR because behaviour is pretty weird sometimes and not very consistent but still...

[huhn]

you are using DXVA native with that decoder and a trade quality for performance option DXVA chroma upscaling is used.

[sexus]

lols , that explains alot, i was wondering what in hell was going on

[ryrynz]

Madshi, playing back a 512x384 AVI file when 'delay playback start until render queue is full' is ticked causes the video not to stretch to fullscreen in MPC-BE.
Unticking this option the video scales to fullscreen, Aleksoid has also confirmed it. Sample file here (http://pan.baidu.com/wap/shareview?&shareid=2821055028&uk=1258452735&dir=%2F%E6%A2%81%E9%9D%99%E8%8C%B9%2FMV&page=2&num=20&fsid=2312385777&third=0&).

[baii]

what?
Was replying to player freeze when doing a seek, the quote didn't come through...

Sent from my 306SH

[madshi]

I wasn't able to make a screenshot in fullscreen mode but made in windowed (render times should be lower in fullscreen anyway because it doesn't need to upscale/downscale)
http://i.imgur.com/PvuPr96.jpg
It might be a bug in recent madVR because behaviour is pretty weird sometimes and not very consistent but still...
In what way is it "pretty weird" and "not very consistent"? You're not giving me a lot of details here.

Madshi, playing back a 512x384 AVI file when 'delay playback start until render queue is full' is ticked causes the video not to stretch to fullscreen in MPC-BE.
Unticking this option the video scales to fullscreen, Aleksoid has also confirmed it. Sample file here (http://pan.baidu.com/wap/shareview?&shareid=2821055028&uk=1258452735&dir=%2F%E6%A2%81%E9%9D%99%E8%8C%B9%2FMV&page=2&num=20&fsid=2312385777&third=0&).
It seems that MPC-BE fails to call "IBasicVideo::SetDestinationPosition()" when the "delay playback start" option is ticked. I don't know why. Could be a reaction to the way madVR reacts when that option is ticked, but from what I can see in my log, it looks like something that should be fixed in MPC-BE. I don't think there's much I can do here. madVR does what MPC-BE asks for. And that is different (for some weird reason) when that option is ticked vs not ticked.

I updated my madVR and noticed a lot of options in trade quality for performance checked (from top all the way to don't render if fade in/out). Do they have any noticeable impact on picture quality? What options are safest to have enabled and what my cause visible "artifacts"?
I've selected those by default which I find give a good performance boost for only a minor loss in image quality. Of course you're very welcome to do image quality comparisons and disagree on my default selection. If your GPU is fast enough and you don't want to sacrifize any quality at all (unless it's really pretty much zero), then uncheck all those options.

I did optimize several of the DXVA related processing paths, so some improvement is expected, when using DXVA stuff.

v87.18 freezes on fastforward / seek. Have to kill the player process manually to get out of it.
That should be fixed in the next build.

[madshi]

madVR v0.87.19 released

http://madshi.net/madVR.zip

* fixed: seeking sometimes froze (e.g. with Haali Splitter)
* fixed: DXVA scaling with "use a separate device for DXVA" -> black screen

[Kirk Lazarus]

Hi Madshi, many thanks for your feedback also if I'm a newbie.


Is the display even able to sync to the display mode? Do you know that? My projector complains if it can't sync. Does yours?

How I can verify this?

I might be able to see something if you upload a (zipped) debug log somewhere (not here) and link to it here.

I hope that "freeze-report" is equal to the debug-log file you asked me ...

HERE (https://dl.dropboxusercontent.com/u/261382755/madvr_report.zip) two freeze-reports.

The first one is without the check on "use fullscreen exclusive mode"; the second is with the check ON and during the black screen.

Let me know.
Thank you

[TheShadowRunner]

* fixed: seeking sometimes froze (e.g. with Haali Splitter)
Thank you madshi, fixed indeed.

[madshi]

I hope that "freeze-report" is equal to the debug-log file you asked me ...
The freeze report is useful when the media player appears to be frozen (GUI doesn't react, anymore). As long as the media player still fully reacts to your mouse/keyboard, a freeze report usually doesn't help. In that case I need a debug log, which you can get by double clicking "activate debug mode.bat" with your media player closed. Then reproduce the issue, wait 10 seconds, close your media player. Then you should have a debug log on your desktop. Afterwards run "activate release mode.bat". The debug log gets very big very fast, so please zip it.

[vomanci]

* fixed: DXVA scaling with "use a separate device for DXVA" -> black screen[/code]

Works good now

[kasper93]

@madshi: When using "separate device for presentation" and presentation queue is not filling fast enough or render queue (I don't know which one is the cause) madVR draws frames in random order (this include OSD). We can see frame where OSD message is gone and after that flashes from frames with OSD message. I don't see it as a bug because without using "separate device for presentation" it is also not playable, but frames are dropped in more sane way, I mean old frame presist on screen and new frame is drawn when ready, no old frames flashes. Is it known/intended behavior? Maybe there is some synchronization issues? I can send a log file if needed.

This happens only on Intel GPU. I never seen this on AMD. Can't tell about NVIDIA.

[flashmozzg]

In what way is it "pretty weird" and "not very consistent"? You're not giving me a lot of details here..

Sorry, It was too late when I was writing it so I couldn't have given more info.
The weird inconsistency/weirdness is observed sometimes when I change time of the video (don't know how to put it - just then I press on progress bar). It's sometimes gives me 20+-5ms rendering times but after about 30 secs it goes back to normal.
But this is not all. I opened small 288p video for what I had 3ms render times before and it had 18ms render times but as soon as I changed time with progress bar - it went back to normal 2-3ms.
And I can't say it's really reproducible.

For example just now - I started the video (of which I posted screenshot before) and it had like 32ms render times. But when I went to full screen it became 4ms. After that I wen windowed and it went back to 32ms and staid like this for a while without changing. When I switched time a little again and it immediately started decreasing going back to 5-6ms after a while.

you are using DXVA native with that decoder and a trade quality for performance option DXVA chroma upscaling is used.
lols , that explains alot, i was wondering what in hell was going on
I disabled I disabled both DXVA upsacling and also BTB/WTW trade quality for performance and my render times stayed almost the same.
http://i.imgur.com/FVR4Uwy.png
EDIT: Disabled every trade quality option except for optimize subtitle, don't use linear light and don't render when fade in/out and it's still roughly 4ms in render times.

[James Freeman]

Anyone cares to share experience about G-sync and madVR?

Apparently a monitor with 144Hz CAN'T sync to custom refresh rates created via nvidia control panel like 47.952Hz or 72Hz.
So maybe madVR/MPC-HC can ask for G-sync instead of V-sync to allow the monitor enable its full range of refresh rates?

[Asmodian]

Sorry, It was too late when I was writing it so I couldn't have given more info.
The weird inconsistency/weirdness is observed sometimes when I change time of the video (don't know how to put it - just then I press on progress bar). It's sometimes gives me 20+-5ms rendering times but after about 30 secs it wents back to normal.
But this is not all. I opened small 288p video for what I had 3ms render times before and it had 18ms render times but as soon as I changed time with progress bar - it went back to normal 2-3ms.
And I can't say it's really reproducible.

For example just now - I started the video (of which I posted screenshot before) and it had liek 32ms render times. But when I went to full screen it became 4ms. After that I wen windowed and it went back to 32ms and staid liek this for a while without changing. When I switched time a little again and it immediately started decreasing going back to 5-6ms after a while.

Watch the power states on your GPU when this is going on. I am pretty sure this is your GPU clocking up and down with load. GPU-Z (http://www.techpowerup.com/downloads/SysInfo/GPU-Z/) might help.

Anyone cares to share experience about G-sync and madVR?

Apparently a monitor with 144Hz CAN'T sync to custom refresh rates created via nvidia control panel like 47.952Hz or 72Hz.
So maybe madVR/MPC-HC can ask for G-sync instead of V-sync to allow the monitor enable its full range of refresh rates?

When madVR enters full screen exclusive G-sync activates now, madVR and Fraps both report ~44 Hz watching 24 fps content for me with smooth motion disabled. With smooth motion enabled the refresh rate seems to change on every seek. I haven't tested smoothness when using G-sync and madVR, I will have to do some more tests later.

One of my G-sync displays has a 24 Hz mode that seems to work well but it is odd I can use 24 - 144 Hz but it will not sync on 48 Hz. :(

[James Freeman]

When madVR enters full screen exclusive G-sync activates now, madVR and Fraps both report ~44 Hz watching 24 fps content for me with smooth motion disabled. With smooth motion enabled the refresh rate seems to change on every seek. I haven't tested smoothness when using G-sync and madVR, I will have to do some more tests later.
Please do!
I am very interested in one of the new 144Hz IPS panel coming around with G-Sync or Freesync.
Did you try with the new refresh rate counter in the latest builds of madVR?


One of my G-sync displays has a 24 Hz mode that seems to work well but it is odd I can use 24 - 144 Hz but it will not sync on 48 Hz. :(

It seems that the software has to specifically request for G-Sync to enable the full range of refresh rate of the monitor.
I guess windows desktop is V-sync DirectDraw only, so not custom refresh will work.
Isn't G-sync needs D3D?

[Olivier C.]

One potential problem with this approach is that if you modify the settings from within your media player, you might overwrite settings the user has already painfully setup himself. Anyway, that's your decision, of course.


Thanks a lot for your fast answer.

You are right. I just want to override the "display mode settings" with the list of supported resolutions and leave the rest intact.


I've zero experience with C#, so I don't know if I can answer your questions. Basically you should create a madVR instance, just like a media player would, then use QueryInterface to turn the madVR instance into an IMadVRSettings interface, then you can use the methods of that interface. Hope that helps?

Yes, it helps, thanks.
I will try to translate this into C# (the less funny part).

Thanks again for all your great stuff Madshi !

[Asmodian]

Please do!
I am very interested in one of the new 144Hz IPS panel coming around with G-Sync or Freesync.
Did you try with the new refresh rate counter in the latest builds of madVR?

I didn't actually, I will do some testing with both v0.87.16 and v0.87.17 tonight.

It seems that the software has to specifically request for G-Sync to enable the full range of refresh rate of the monitor.
I guess windows desktop is V-sync DirectDraw only, so not custom refresh will work.
Isn't G-sync needs D3D?

Actually, software cannot request G-sync as far as I know. G-sync activates anytime anything goes Full Screen Exclusive but it requires Full Screen Exclusive so it cannot activate in any Windowed or desktop modes. V-sync might cause timing issues if it is implemented outside the drivers but the drivers switch to G-sync for everything.

G-sync at 48 Hz runs differently than a 48 Hz sync, it updates the screen at the max refresh rate (usually 144 Hz) and then waits for a new frame while holding vblank. With a normal 48 Hz sync the screen updates at a much slower rate than it would at 144 Hz. Another way to say it is, when updating the screen the pixel clock rate though the DP cable is much lower with 48 Hz V-sync than with 48 Hz G-sync.

An 144 Hz 2560x1440 IPS monitor is a great display for madVR, even if it is probably overkill. Smooth motion is great at 144 Hz and I don't feel the need for true exact refresh rates, but still it would be cool to have madVR use G-sync if it can be done well. ;)

[Digiface]

Seeking works again with 0.87.19. Thanks!

[Kirk Lazarus]

...The debug log gets very big very fast, so please zip it.

HERE (https://dl.dropboxusercontent.com/u/261382755/madlog.zip) the debug file.

thank you

[nevcairiel]

Anyone cares to share experience about G-sync and madVR?

Apparently a monitor with 144Hz CAN'T sync to custom refresh rates created via nvidia control panel like 47.952Hz or 72Hz.
So maybe madVR/MPC-HC can ask for G-sync instead of V-sync to allow the monitor enable its full range of refresh rates?

GSYNC doesn't really work with video playback.

The way GSYNC is meant to function is that it sends every image as fast as possible to the screen for immediate presentation (up to the 144Hz limit, of course).
The way a video renderer works is that it knows that your screen runs on X Hz, and it renders video frames in advance to match that refresh rate. It needs to output the frames right at the time it calculated, and not when the GPU and screen think the next one needs to go out.

In short, video renderer design and GSYNC are not going to work well together at all.

A video renderer could probably be built to make use of the variable-refresh characteristics of GSYNC, but that would be a rather specific design for a gaming-oriented feature thats not likely going to be present on TVs or projectors ... so seems kinda pointless.

If you can run 144Hz, you should probably just run Smooth Motion (the higher the refresh, the better SM is going to look), or switch between 100 (for 25/50 fps), 120 (for 30/60 fps) and 144 (for 24/48 fps) for all the common media frequencies around.

[Asmodian]

I understand that FreeSync (AMD's version of G-sync) is intended for video playback, at least it is being marketed for such. Some of their GPUs even support FreeSync only for video playback, not games (I don't know the technical reasons for this).

"All" a render would need to do to use G-sync or FreeSync is present frames only when it wants them displayed and rely on the drivers to display them with very little (and consistent) delay. The issue, as I understand it, is doing this present with somewhat accurate timing. The nice thing about G-sync is that if a frame present was delayed a few ms it doesn't need to wait for a full refresh cycle, it simply displays that frame a bit late. You don't even want to pay attention to when each frame was actually presented, simply attempt to present each frame when it should be presented compared to the audio clock. With G-sync even the lower refresh rate limit isn't an issue, the module will take care of doubling frames and even shifting the refresh rate to make it very unlikely that an early or late frame would hit during scan out.

madshi has stated that this would probably provide a worse experience than simply using the current method even without smooth motion because Windows' timing simply isn't very precise and I don't have any reason to believe madshi is wrong. I would still like to see it, it could be quite interesting for mixed fps content, but implementing a feature that is likely to make playback worse and frame times technically less precise only for the geek factor of playing with new technology doesn't seem to be high among madshi's priorities. ;)

I really have no complaints with the quality of madVR's smooth motion at a fixed 144 Hz with any content. :D

[nijiko]

Will you plan to support x64? :(

[ryrynz]

Will you plan to support x64? :(
Support will come, it's on Madshi's to do list. I do believe he has some other features he wishes to add first.. But fingers crossed we'll see a 64 bit version this year.

[Asmodian]

Please do!
I am very interested in one of the new 144Hz IPS panel coming around with G-Sync or Freesync.
Did you try with the new refresh rate counter in the latest builds of madVR?

I did some testing with madVR v0.87.19 and v0.87.16 with G-sync and without smooth motion. There wasn't much to distinguish between the two versions.

The refresh rate was always detected as near but not quite a multiple of the frame rate. Motion was always choppy with it being worse or better depending on what madVR thought the current refresh rate was. Using a 23.976 fps movie; when madVR thought it was 49.5 Hz there was chop less often than when it thought the refresh rate was 44 Hz but when it thought the refresh rate was 74 Hz motion was a little better still. The detected refresh rate would change on seeking or reopening the file and sometimes while playing. It is curious that madVR never thought the refresh rate was the frame rate or an exact multiple of it.

With rendering times above the frame time (so the present buffers stayed empty) the detected refresh rate jumped around a lot more but it also kept the detected refresh rate near the frame rate, never a multiple of it.
edit: actually I think this kept the detected refresh rate near the rendering rate not the frame rate of the video file. :o

Fraps always reported the same frame rate madVR detected.

It seems like it would work well if madVR simply assumed the refresh rate was whatever frame rate it wanted to render at but I really have no idea.

Using a fixed 120 Hz instead of G-sync was much better.

Will you plan to support x64? :(

Yes, maybe sooner rather than later now but no ETA. :)

[Nachbar]

I'd like to report a bug.

I'm not sure which program is at fault here but if you are playing a video with mpc-hc and then close it when you have amd gaming evolved (raptr) running then mpc-hc will get stuck running in the background and it will eat up one of your cpu cores until you close it via task manager. If I do not use madvr this does not occur. Also if I close raptr while mpc-hc is stuck in the background I will then get a message that mpc-hc has stopped working and it will close. If I don't have raptr running then everything is fine.

I'm going to guess its raptr having the problem as I've tried madvr 87.14 and I still get the problem there.

Does it still occur with v0.87.17? If so, I'm not sure what it could be. You could try pressing Ctrl+Alt+Shift+Break. Then wait a few seconds. Do you then get a freeze report text file on your desktop? If so, post it somewhere for me to look it (not here in the forum) and post a link here.

Its still occurring with 87.19. When it hangs it is not visible at all. and mad is not visible in the tray. The only way i noticed was because my computer was acting slow so I took a look at my task manager and noticed mpc-hc was using 25% (1 of my 4 cores) when it should be closed. However now with this version after about a minute MPC-HC will pop up with this message:
http://i.imgur.com/pEOwfhM.png
Its the same message I would get with version .14 and .16 when I would instead close raptr.

pressing the key combination during this does nothing.

What I've noticed with this version is that if I am multi-monitor it will take about a minute before that message pops up. If I am single-monitor it is instant when I close mpc-hc.

edit: I tried pressing the key combination during normal playback and this is what I get: https://www.mediafire.com/?ov472bzg7nb81zv

[iSunrise]

G-SYNC (which is an implementation of variable refresh rate technology, but modified in some aspects) is not fit for video content, because part of NV's variable refresh rate implementation is that there is a hard-coded low VRR threshold (which depends on the panel and the scaler firmware), meaning, there's a minimal refresh rate that is build into every G-SYNC monitor firmware, which tells the G-SYNC module to "multiply" the current fps by an X amount (doubling, trippling, quadrupling, etc.) so that the screen keeps refreshing above that threshold.

So if you want to use G-SYNC for your display in the range of 23.976fps to around 30fps (fixed threshold value), G-SYNC will effectively double to be well over the threshold again (e.x. 23.976fps should theoretically be displayed at ~47,952Hz).

However, since madVR is relying very heavily on detecting the correct and current refresh rate of your display with preferably very low variation, it seems that the refresh rate is not reported correctly.

It seems like it would work well if madVR simply assumed the refresh rate was whatever frame rate it wanted to render at but I really have no idea.
If madVR goes into exclusive fullscreen, madshi could theoretically implement "a bypass" for the refresh rate detection altogether and let G-SYNC do it's work. However, in that case audio would lag behind and you would also need to use something like Reclock to adapt. However, since Reclock probably has it own problems to get the effective refresh that the G-SYNC module is feeding the screen, this is also a no-go.

Like nevcairiel posted, we should just forget about G-SYNC, because in it's current implementation it is solely targeted for gaming and not for video applications.

The variable refresh rate standard, however (e.x. implemented through FreeSync), could be used as a base for video applications, but madshi would probably need to write a lot of code for that to work correctly and then we would also have the problem that this requires DP to work (nevcairiel mentioned it) and thus is completely unfit for TV, projectors or similar devices that are not primarily meant for gaming.

So we are again stuck to use multiples or (when available) native Hz and fiddle around with values to arrive at a good sync. A damn shame, really.

[nevcairiel]

FreeSync really has the same problems, as displays have issues with very low refreshes, as the image decays. FreeSync also has a minimal refresh, usually in the 30-40 fps range.

[iSunrise]

FreeSync really has the same problems, as displays have issues with very low refreshes, as the image decays. FreeSync also has a minimal refresh, usually in the 30-40 fps range.
I find it important to differentiate though, that these limits are not inherent to the variable refresh rate standard (FreeSync is just an implementation of it), it's just that most of the current panels are seriously limited in that aspect. So I wouldn't call this a FreeSync limitation in the sense that FreeSync has a minimal refresh, it's more related to the HW that FreeSync currently has to work with.

G-SYNC also has to work with these same limitations in mind, obviously, but it provides some additional tricks to work-around them. In the grande scheme of things, we are panel technology-limited, not really the fault of the variable refresh rate standard.

[madshi]

HERE (https://dl.dropboxusercontent.com/u/261382755/madlog.zip) the debug file.
According to the log, everything seems to run smoothly. The log says you're running on 3840x2160 at 23.976Hz, and it stays the same when switching into fullscreen exclusive mode. So I don't really know why you would get a black screen. Doesn't make much sense to me. Do you get a picture when using fullscreen exclusive mode with EVR in fullscreen exclusive mode (e.g. in MPC-HC or MPC-BE)?

When using "separate device for presentation" and presentation queue is not filling fast enough or render queue (I don't know which one is the cause) madVR draws frames in random order (this include OSD). We can see frame where OSD message is gone and after that flashes from frames with OSD message. I don't see it as a bug because without using "separate device for presentation" it is also not playable, but frames are dropped in more sane way, I mean old frame presist on screen and new frame is drawn when ready, no old frames flashes. Is it known/intended behavior? Maybe there is some synchronization issues? I can send a log file if needed.

This happens only on Intel GPU. I never seen this on AMD. Can't tell about NVIDIA.
Hmmmm... I've seen this, too, but wasn't sure about the cause. Would you mind creating an issue in the bug tracker, so that I don't forget about this? Might be a while before I find the time to look into it...

The weird inconsistency/weirdness is observed sometimes when I change time of the video (don't know how to put it - just then I press on progress bar). It's sometimes gives me 20+-5ms rendering times but after about 30 secs it goes back to normal.
But this is not all. I opened small 288p video for what I had 3ms render times before and it had 18ms render times but as soon as I changed time with progress bar - it went back to normal 2-3ms.
And I can't say it's really reproducible.

For example just now - I started the video (of which I posted screenshot before) and it had liek 32ms render times. But when I went to full screen it became 4ms. After that I wen windowed and it went back to 32ms and staid like this for a while without changing. When I switched time a little again and it immediately started decreasing going back to 5-6ms after a while.
As long as the queue needs to be filled, maybe rendering times could be higher, I'm not sure. Anyway, doesn't really matter.

Its still occurring with 87.19. When it hangs it is not visible at all. and mad is not visible in the tray. The only way i noticed was because my computer was acting slow so I took a look at my task manager and noticed mpc-hc was using 25% (1 of my 4 cores) when it should be closed. However now with this version after about a minute MPC-HC will pop up with this message:
http://i.imgur.com/pEOwfhM.png
Its the same message I would get with version .14 and .16 when I would instead close raptr.

pressing the key combination during this does nothing.

What I've noticed with this version is that if I am multi-monitor it will take about a minute before that message pops up. If I am single-monitor it is instant when I close mpc-hc.

edit: I tried pressing the key combination during normal playback and this is what I get: https://www.mediafire.com/?ov472bzg7nb81zv
Ok, thanks. Unfortunately I forgot to tell you that you also need to download the PDB files for MPC-HC (and they need to match exactly the MPC-HC version you're using). I'm sorry. Could you please get those PDB files and the upload another freeze report? I'm still not sure it will help, but maybe it will.

[Asmodian]

However, since madVR is relying very heavily on detecting the correct and current refresh rate of your display with preferably very low variation, it seems that the refresh rate is not reported correctly.

Yes, madVR could not rely on a detected refresh rate for anything when using G-sync (the refresh rate isn't a constant that could be accurately detected). The only reason madVR wants to know the refresh rate is because it needs to sync to it. With variable sync madVR could drop the entire concept of a display refresh rate. Because the frame duplication is handled by G-sync madVR could completely ignore it.

I don't understand why this behavior makes it "unfit for video content". Variable Sync is Variable Sync, they all work basically the same way. As soon as a frame is available you display it and then hold vblank until the next frame is available. Double each frame if near or below the minimum refresh rate.

Video content is exactly the same any any other content once we have frames of video information. All madVR would need to do is present frames when it thinks they should be displayed. madVR could do the doubling too, if madshi wanted to support FreeSync as well.

If madVR goes into exclusive fullscreen, madshi could theoretically implement "a bypass" for the refresh rate detection altogether and let G-SYNC do it's work. However, in that case audio would lag behind and you would also need to use something like Reclock to adapt. However, since Reclock probably has it own problems to get the effective refresh that the G-SYNC module is feeding the screen, this is also a no-go.

Why would the audio lag behind the video? Wouldn't each video frame be displayed at the correct time to match the audio? In fact the present times for each video frame would be best calculated from the audio clock and madVR wouldn't need to watch the video clock at all. Effectively Reclock for the video instead of the audio.

The variable refresh rate standard, however (e.x. implemented through FreeSync), could be used as a base for video applications, but madshi would probably need to write a lot of code for that to work correctly and then we would also have the problem that this requires DP to work (nevcairiel mentioned it) and thus is completely unfit for TV, projectors or similar devices that are not primarily meant for gaming.

G-sync is just as suited for video as the standard in DP 1.2a A-Sync, in fact madVR wouldn't even need to know which it was using. Simply rely on the GPU and drivers to display frames when it presents them. You need a variable sync compatible display, of course. If a projector was compatible with variable sync it would work, if not it wouldn't. DP would available on any variable sync compatible display, by definition, given the current technology.

So we are again stuck to use multiples or (when available) native Hz and fiddle around with values to arrive at a good sync. A damn shame, really.

I don't like tuning the refresh rate to match, especially as the target refresh rate isn't the exact refresh rate of the video but slightly offset due to variations in the video clock.

@madshi, I am sorry I keep going on about this in your thread when I know you aren't very interested in variable sync. I am simply very excited to finally own displays without fixed refresh rates. It seems like the holy grail for video playback (even as I believe it wouldn't actually be better than the current technique of smooth motion at 144 Hz). :o

Does smooth motion need to drop or repeat frames to maintain audio sync?