madVR - high quality video renderer (GPU assisted)

[QBhd]

@ 6233638 .... LOL it wasn't a typo, but you did mis-read what I said. All other tests led me to believe it was NOT 4:4:4 and this test clearly shows that my guess was correct. This test is very clear and very easy to interpret. Again thanks for this image!

QB

[Q-the-STORM]

PC/Game mode. (4:4:4)
http://www.abload.de/img/_dsc30695esoj.jpg

And Cinema mode. (4:2:2)
http://www.abload.de/img/_dsc30682ms0w.jpg


thank you very much for this.... "roughly the same magenta color" is not really a very specific description, and what a "obvious difference" and a "subtle difference" is, is very subjective....
your pictures make it clear, I do have 4:4:4...

[rurifan]

When you are looking at the pattern normally, there is a slight difference between both halves in PC/Game mode (4:4:4) but that is to be expected.
The difference with 4:2:2 chroma should be an obvious one, as the photos illustrate.

Is there a reason to use that line pattern with the semi-confusing description (it only makes sense once you've seen it) rather than a circle test like this one (http://i.imgur.com/gTsKnxk.png)?

I was thinking maybe madshi ought to ship a test pattern with madvr so normal people will know to fiddle their HDTV settings.

[ryrynz]

I'm very :confused: as to the problem.

I implied you should try Fullscreen Exclusive, also have you tried Windowed overlay?

[baii]

Sorry for another video card related question

Would gddr3 vs gddr5 vram have any impact on madvr performance, specifically looking at the 6650m vs 6750m.

[nevcairiel]

Would gddr3 vs gddr5 vram have any impact on madvr performance, specifically looking at the 6650m vs 6750m.

Yes, quite a bit even. GDDR5 can be much faster on memory heavy operations.

[Qaq]

Is it normal for madVR to only detect one of my two connected and identical make/model monitors? I only see one device in madVR's device list...
I tried to complain on this and was told "buggy drivers".

[berga.d]

Hi madshi, I'm testing madVR under Win 8.1. It seems I found a problem with the new per-screen dpi setting that's new in 8.1: it causes madVR to stay in "windowed" mode even at fullscreen. Win 8.1 defaults to a different dpi for each screen connected. It sets the system dpi to the one of the main screen at boot time, and then it scales through dwm any app that doesn't use the new dpi api.
Thanks for your work

[huhn]

What is your flush setting? If you turn off all of them, what rendering time does it show? With 120Hz output mode, it is obviously that the rendering time needs be less than 8.333 ms -- usually much safe with the value near 5 ~ 6ms.

How about the case with 60Hz output mode?

it doesn't need to be below 8.33 ms 17 ms is ok the source is 48 fps not 120 fps. the peak of ~25 ms is the problem.


Okay, setting CPU queue to 128 helped - at one point the queue fell to 40/128
All the points were playback would "hang" had this problem (though none that badly).

the clip you are using it not an normal clip so i take it back your cpu is a problem too. as long as you can't make the cpu queue stable madvr will not run stable.


you can try to restart the driver that helps me alot with empty backbuffers.

open taskmanager search for ccc.exe kill it and open a new catalyst control center.

but i think the real problem is the vram speed.

[chano22000]

Dear 6233638

Thank you for your time and answser http://forum.doom9.org/showpost.php?p=1634859&postcount=19374

Kind regards.

[pie1394]

it doesn't need to be below 8.33 ms 17 ms is ok the source is 48 fps not 120 fps. the peak of ~25 ms is the problem.


madshi, is this true when the "smooth motion" option is on?

[huhn]

just try it out:

http://s3.imgimg.de/uploads/test15806196png.png

[Asmodian]

As an aside, I don't know why madVR only shows one device in the devices list. [...] Also, how can I apply different 3DLUTs to both monitors? I tried to add the device within madVR but that doesn't work with the second display either.

I tried to complain on this and was told "buggy drivers".

I use CRU to change the names of the identical monitors. I just added a -1, -2, -3 to the end of the names and MadVR sees three different monitors now. For some reason resolutions added with CRU stopped working (they do not show up at all) but the name change still works, nvidia+Win8.

[dansrfe]

I use CRU to change the names of the identical monitors. I just added a -1, -2, -3 to the end of the names and MadVR sees three different monitors now. For some reason resolutions added with CRU stopped working (they do not show up at all) but the name change still works, nvidia+Win8.

Wow, I used CRU a while back but didn't think to use it for this. I straightened out all the custom refresh rates and renamed the monitors just like you suggested with -1, -2. I removed and disabled the custom resolutions in nvidia cpl as well. Now both monitors show up distinctly in madVR devices list and nvidia cpl shows the custom resolutions set in CRU as native resolutions. Thanks!

[karamancho]

while we're at it, my laptops 'generic pnp display' is shown as 'Epson DM110141W1 #-5JfŚÜ' in madvr. any ideas why?

[YxP]

Is there a reason to use that line pattern with the semi-confusing description (it only makes sense once you've seen it) rather than a circle test like this one (http://i.imgur.com/gTsKnxk.png)?

Something to do with gamma calibration as well? http://www.phototopics.net/ptgamma.gif

[AngelGraves13]

madshi, can you please add chapter markers in the seek bar for exclusive mode similar to how MPC HC/BE does it?

[konakona]

I've got a question about connecting tv to my htpc,namely 40ex500 bravia tv to an nvidia gtx660.
From what I've heard,nvidia cards automatically do limited range rgb from hdmi output,unless you change that in registry. I can also switch from RGB to YCbCr from nvidia control panel.
So:

-if i connected it "as is",meaning limited range rgb,should i tell madvr that my tv excepts limited or full range? (blacks looks really washed out when i tell madvr that tv is expecting limited range;from what i understand madvr first converts full to limited,and then nvidia converts from limited to even more limited range)

-if connected as full range,should i tell madvr that my screen expects pc or video levels?

-last,but not least-should i use the limited/full range rgb,or the YCbCr444 output? (logically assuming,YCbCr is unwanted because of double colour space conversions)

[turbojet]

Any suggestions how to fix empty backbuffer in window mode with frc on and any external program using gpu (changing windows, opening new chrome/firefox tab, etc.)?

Changing flush settings, resizers, or queue sizes had no effect. Disabling use external device for presentation made it worse by leaving backbuffer always empty. Disabling frc, using overlay, or using fse eliminated it but want to use window mode for multple players and taskbar preview.

This happens with nvidia gts250, 9500gt, hd2000. Other queues stay full. CPU can be as low as 5%, GPU as low as 15% when it's happening. Maybe it's a bug?

[mindbomb]

amd and nvidia drivers have an option in the video section to choose 0-255 or 16-235 for dynamic range.
I assume this is for the evr renderer and has no effect on madvr, right?

[QBhd]

amd and nvidia drivers have an option in the video section to choose 0-255 or 16-235 for dynamic range.
I assume this is for the evr renderer and has no effect on madvr, right?

Correct as far as I know!

QB

[namaiki]

Correct as far as I know!

QB

I think it may have an effect on the DXVA resizers and on the deinterlacing, but then madVR checks the value at the start and adjusts for it.

[gendouhydeist]

Hi guys is there anyway to change resolution when playing a video with madVR? cause i set mine to 1440x900 and I wanted it to change resolution to 1920x1200 when playing a video so it won't downscaled videos and return to default resolution after using it. Also I've read somewhere here in forum that you can force madVR to use specified settings in txt format by putting it inside the madVR folder I just don't know where to find it.

[Moragg]

I implied you should try Fullscreen Exclusive, also have you tried Windowed overlay?

Windows Overlay doesn't work with my GPU.

I tried Fullscreen Exclusive, it worked, but not by utilising the full GPU - it peaked at 50%. Not sure if this means madvr wasn't using smooth motion (FRAPS says with/without SM exclusive forces 120Hz).

Also: will HEVC H.265 increase demand on CPU/GPU/both and by how much?

[michkrol]

Hi guys is there anyway to change resolution when playing a video with madVR? cause i set mine to 1440x900 and I wanted it to change resolution to 1920x1200 when playing a video so it won't downscaled videos and return to default resolution after using it.

Not sure why you would want to not use native resolution (do you have a CRT?), but Windows 7 (and newer) has quite good scaling options, if the text and buttons are to small for you, so give them a try.

As for your question: go to madVR settings, select: devices -> your display -> display modes
For your case probably best to select both:
switch to matching mode ... when player goes fullscreen;
restore original mode ... when player leaves fullscreen;
be sure to input desired mode(s) below, in your case enter only the 1200p60(?) resolution of course, apply settings and you're done.

Also I've read somewhere here in forum that you can force madVR to use specified settings in txt format by putting it inside the madVR folder I just don't know where to find it.
I don't remember anything like that, so can't help you here. It is possible to add certain tags to videos filenames, but it might be not what you're looking for.

[huhn]

Windows Overlay doesn't work with my GPU.

I tried Fullscreen Exclusive, it worked, but not by utilising the full GPU - it peaked at 50%. Not sure if this means madvr wasn't using smooth motion (FRAPS says with/without SM exclusive forces 120Hz).

Also: will HEVC H.265 increase demand on CPU/GPU/both and by how much?



h265 only affect the cpu. there aren't any good decoder yet so who knows.

madvr only cares about fps chroma subsampling and resolution. so xvid vp7-9 h264 all that doesn't matter.

[mindbomb]

blacks looks really washed out when i tell madvr that tv is expecting limited range;from what i understand madvr first converts full to limited,and then nvidia converts from limited to even more limited range


Oh, is this true? That seems pretty weird that you can't just tell madvr to output limited range in this scenario.

[sgraves66]

I'm trying to use madVR for full-screen only and write directly to an OpenGL surface during windowed-mode. To accomplish this, I'm simply hiding the madVR window when necessary. CPU usage is a bit higher, but it's quite usable in general. Unlike previous designs, I don't create madVR as a child of any top-level window. I'm experiencing issues, such as the renderer window not fully filling the screen (intermittent) and switching out of FSE, when enabled, doesn't retain hidden status (seems like after the 3 second delay, visibility returns). I have a dedicated message pump in an isolated thread that's used only by DirectShow. I thought this would be the most efficient way to separate OpenGL from DirectShow/Win32 for smooth playback.

Do you recommend always specifying a parent window, especially when FSE is enabled? It wouldn't be a big change, but was hoping to alleviate the need for anything other than a notification window for events.

[madshi]

What are the pros/cons of disabling "use inverse telecine" in the nvidia control panel? With madvr now having its own version of ivtc should i just leave the option unchecked?
madVR's IVTC needs to be manually enabled. Or you can leave it on all the time, but then you may have to manually disable it for true video content. If you can live with having to manually switch madVR's IVTC algorithm on/off once in a while then you don't need NVidia's IVTC. If you prefer to have everything done automatically, you can disable madVR's IVTC algorithm and use DXVA deinterlacing instead. Then it would make sense to turn NVidia's "inverse telecine" on. The disadvantage is that NVidia doesn't decimate. So 60i is converted to 60p instead of 24p. So you'll still have the 3:2 pulldown judder. This problem does not happen with madVR's IVTC algorith, which properly decimates to 24p.

Leave it checked. The pro is that the nvidia one works automatically. The con is that if you are using madvr to change display modes (1080p23 for example), madvr won't know that ivtc is being done and will choose the wrong refresh rate.
More or less correct. However, the problem is not what madVR knows or doesn't know. The problem is that DXVA can't really do decimation, technically.

GPU usage isn't going above 57% yet I still get dropped frames. This is Jinc3+AR+SmoothMotion

Upping it to Jinc8 AR uses the whole 100%, so why can't it use 100% at Jinc3 to not drop frames?
Your GPU and backbuffer queues are rather small. Try increasing them. Especially SmoothMotion benefits from larger queues.

Other users have found that the backbuffer queue often gets empty (which seems to be the main cause of trouble for you, too) if you run other software in the background which also uses the GPU. So try closing all software that might eventually talk to the GPU or use GPU power, even your browser. Does that "fix" the problem?

I turned fullscreen exclusive off since I didn't like it.
Well, I can understand that, but then FSE mode really does produce the most reliable playback for most users.

I tried Fullscreen Exclusive, it worked, but not by utilising the full GPU - it peaked at 50%. Not sure if this means madvr wasn't using smooth motion (FRAPS says with/without SM exclusive forces 120Hz).
Did you have any frame drops? If not, then probably 50% was simply enough to perform all the rendering...

Is it normal for madVR to only detect one of my two connected and identical make/model monitors? I only see one device in madVR's device list...
Hmmmm... Two identical monitors? That's mean... :o Do they have an EDID block? Feel free to create a bug entry for this in the madVR bug tracker. I might have to fix this blindly, though, because I don't have 2 identical displays to test with...

Hi madshi, I'm testing madVR under Win 8.1. It seems I found a problem with the new per-screen dpi setting that's new in 8.1
Please retest this when 8.1 goes official. If the problem then still occurs, please create a bug entry in the madVR bug tracker. Thanks.

it doesn't need to be below 8.33 ms 17 ms is ok the source is 48 fps not 120 fps. the peak of ~25 ms is the problem.
Peaks don't have to be a problem as long as the queues stay full.

madshi, is this true when the "smooth motion" option is on?
Smooth motion does not render at the refresh rate. It renders only so many frames as necessary to achieve smooth motion. So you don't necessarily have to be under 1000/refreshRate milliseconds. There will be a certain threshold you need to stay under, but it's not as easy as 1000/refreshRate, at least not if the movie framerate is much lower than that...

while we're at it, my laptops 'generic pnp display' is shown as 'Epson DM110141W1 #-5JfŚÜ' in madvr. any ideas why?
That's probably what the EDID says.

madshi, can you please add chapter markers in the seek bar for exclusive mode similar to how MPC HC/BE does it?
Not anytime soon, sorry. Feel free to ask again after madVR has reached v1.0.

I've got a question about connecting tv to my htpc,namely 40ex500 bravia tv to an nvidia gtx660.
From what I've heard,nvidia cards automatically do limited range rgb from hdmi output,unless you change that in registry. I can also switch from RGB to YCbCr from nvidia control panel.
So:

-if i connected it "as is",meaning limited range rgb,should i tell madvr that my tv excepts limited or full range? (blacks looks really washed out when i tell madvr that tv is expecting limited range;from what i understand madvr first converts full to limited,and then nvidia converts from limited to even more limited range)

-if connected as full range,should i tell madvr that my screen expects pc or video levels?

-last,but not least-should i use the limited/full range rgb,or the YCbCr444 output? (logically assuming,YCbCr is unwanted because of double colour space conversions)
My recommendation is always to set configure your display so that it expects PC levels (full range). This has 2 important benefits: (1) Levels will be correct for everything, including games, photos, applications and video playback. (2) There should be no problem with image quality.

If your display can't do PC levels, or if you have good reasons for not using this solution, then you have 2 alternative solutions:

(a) Either set the GPU to limited range and madVR to PC levels. This means madVR will render to PC levels and the GPU will afterwards stretch the madVR output (and desktop, games, applications, photos etc) to limited range. Using this approach still has the benefit of having correct levels everywhere. But image quality might suffer because the GPU usually uses a rather bad stretching algorithm, which can introduce banding artifacts.

(b) Or set the GPU to fullrange and madVR to TV levels. This will result in good image quality (no artifacts) and correct levels for video playback. However, desktop, games, applications and photos will have wrong levels.

Oh, is this true? That seems pretty weird that you can't just tell madvr to output limited range in this scenario.
It's not weird at all. If you set the GPU to limited range, it will take the output of every application (including madVR, games and desktop) and stretch it behind the back of those applications from 0-255 to 16-235. If you tell madVR to render in limited range, then if the GPU does another 0-255 to 16-235 stretch, you'll end up with a double stretch.

amd and nvidia drivers have an option in the video section to choose 0-255 or 16-235 for dynamic range.
I assume this is for the evr renderer and has no effect on madvr, right?
I think it may have an effect on the DXVA resizers and on the deinterlacing, but then madVR checks the value at the start and adjusts for it.
Correct.

Any suggestions how to fix empty backbuffer in window mode with frc on and any external program using gpu (changing windows, opening new chrome/firefox tab, etc.)?
Well, if there's a 100% reliable way to reproduce this, and if the backbuffer queue is really the only problem, then you can create a bug entry in the madVR bug tracker for this. I can only do anything (if at all) if I can reproduce it, though. So do your best to create a good step-by-step guide that allows me to reproduce the problem on my PC. I can't promise that there is anything I can do about it, though. It must just be a limitation of normal windowed mode. That's why I added Overlay and FSE modes...

I suppose you did try to use a larger backbuffer queue and it didn't help?

I'm trying to use madVR for full-screen only and write directly to an OpenGL surface during windowed-mode. To accomplish this, I'm simply hiding the madVR window when necessary. CPU usage is a bit higher, but it's quite usable in general. Unlike previous designs, I don't create madVR as a child of any top-level window. I'm experiencing issues, such as the renderer window not fully filling the screen (intermittent) and switching out of FSE, when enabled, doesn't retain hidden status (seems like after the 3 second delay, visibility returns). I have a dedicated message pump in an isolated thread that's used only by DirectShow. I thought this would be the most efficient way to separate OpenGL from DirectShow/Win32 for smooth playback.

Do you recommend always specifying a parent window, especially when FSE is enabled? It wouldn't be a big change, but was hoping to alleviate the need for anything other than a notification window for events.
That sounds like a weird way to use madVR. I don't really know what to recommend here. The renderer window not fully filling the screen sounds like something that you should be able to fix yourself by using IVideoWindow::SetWindowPosition()? Not sure about the hidden status. In the worst case I guess you could use Detours (or some other API hooking solution) to hook ShowWindow() and related APIs to block madVR from making itself visible again? To be honest, I'm not really sure who makes the madVR window visible again, could also be Direct3D or the MS base classes on which madVR is built. Don't really know...

[madshi]

madVR v0.86.7 released

http://madshi.net/madVR.zip

* added "madTPG.exe" test pattern generator for calibration purposes
* added support for combined 3dlut/VideoLUT file format ("collink -H")
* option "Disable GPU gamma ramps" should now work in windowed mode, too
* fixed: #30: ZoomPlayer got stuck in 'on top' mode after leaving FSE
* fixed: #90: wrong refresh rate (23/24, 59/60) in win8 in FSE mode
* fixed: #91: added madVR version information to settings dialog
* fixed: #92: shaders were not applied to XySubFilter subtitles
* fixed: #93: overlay mode ignored ICC VideoLUTs
* fixed: pixel shader VideoLUT implementation didn't use linear filtering
* fixed: crash when display mode is changed externally (DXVA processing)
* XySubFilter: improved subtitle upload performance
* XySubFilter: optimized downscaling of bitmap based subtitles
* XySubFilter: madVR consumer now reports "preferTvLevels = true"
* XySubFilter: improved performance, if provider sends TV levels subtitles

[Vyral]

Thanks madshi. I'll try this new version when I get home.
I'm really interested in "Disable GPU gamma ramps" in windowed mode.

[ryrynz]

Switching between windowed mode (overlay or standard) and FSE...(or maybe it's just launching FSE mode) now takes a good couple of seconds with the whole window being black in the meantime, any chance of speeding back up to the near instantaneous 086.6 levels?

[kasper93]

* added support for combined 3dlut/VideoLUT file format ("collink -H")

Is it new feature? Current collink doesn't support "-H". To link .cal file it uses "-a". But probably it's new and Graeme hasn't upload new builds yet?

Thanks for new release.

[dansrfe]

Switching between windowed mode (overlay or standard) and FSE...(or maybe it's just launching FSE mode) now takes a good couple of seconds with the whole window being black in the meantime, any chance of speeding back up to the near instantaneous 086.6 levels?

I can't confirm this behavior.

@madshi
Overlay mode with ICC VideoLUT works now! Oddly enough windowed mode started working after I fixed the buffer settings last week but overlay feels a bit smoother for some reason so I'll stick with it. Quick question, is it normal for overlay to have some lag while resizing and tearing when moving the window around? I assume so but just thought I'd ask.

I'm not sure if the monitors have an EDID block but when I ran CRU I saw that both monitors had identical names in addition to "Product ID"s so I just appended '-1' and '-2' based on the relative location of the monitors from my perspective. After rebooting madVR showed two devices with those names.

Thanks for the fixes and new features in v0.86.7!

[ryrynz]

I can't confirm this behavior.


I can't either on the HTPC, guess I'll be digging deeper, probably graphics driver related again.. The drawbacks of having the latest and fastest performing driver, luckily it ain't my main playback machine.

[michkrol]

Switching between windowed mode (overlay or standard) and FSE...(or maybe it's just launching FSE mode) now takes a good couple of seconds with the whole window being black in the meantime, any chance of speeding back up to the near instantaneous 086.6 levels?

Can confirm. Going to FSE takes 2-3 seconds, leaving FSE is instantaneous. I'm using Intel HD4000 with drivers v15.31.9.3165 (newest "official") on Windows 7 x64 and MPC-HC (x86 v1.7.0.7572 (a2432e1)). I find it only slightly annoying, but hope the info helps find the cause.

Everything else works as expected. Thanks for the new version!

[dansrfe]

Can confirm. Going to FSE takes 2-3 seconds, leaving FSE is instantaneous. I'm using Intel HD4000 with drivers v15.31.9.3165 (newest "official") on Windows 7 x64 and MPC-HC (x86 v1.7.0.7572 (a2432e1)). I find it only slightly annoying, but hope the info helps find the cause.

Everything else works as expected. Thanks for the new version!

Are you sure you don't have the "delay switch to exclusive mode by 3 seconds" checkbox in exclusive mode settings checked?

[ryrynz]

He doesn't, it's the same issue I posted about, I'm using 15.31.12.64.3204 on the HD 4000.

[bugmen0t]

For you guys with the delay when switching to FSE:
Can it be that the monitor display rate changes when switching from windowed mode (e.g. 23 Hz) to FSE (e.g. switching to 24 Hz then)?

[ryrynz]

Nope, from what I can tell It's just the fact it's switching to exclusive, tried a bunch of options with no effect. It's an Intel driver issue.

[madshi]

probably it's new and Graeme hasn't upload new builds yet?
Correct.

Quick question, is it normal for overlay to have some lag while resizing and tearing when moving the window around?
Yes, unfortunately.

I'm not sure if the monitors have an EDID block but when I ran CRU I saw that both monitors had identical names in addition to "Product ID"s so I just appended '-1' and '-2' based on the relative location of the monitors from my perspective. After rebooting madVR showed two devices with those names.
Hmmmm... I'm not totally sure I understand what CRU does and how it affects madVR. In any case, if the two displays are really identical, do you actually need different settings in the madVR device tab? Shouldn't identical displays also run fine with identical settings?

My problem is this: The current madVR device logic tries to detect the real display, not just "monitor 1" or "monitor 2". Let's say you have 2 different monitors and setup both in madVR. Now let's say you switch them around. The current madVR version doesn't care about which display is connected to which GPU output, so if you switch your two *different* displays around, madVR will still apply the correct settings to the correct display with no changes to the settings needed.

Now having two identical displays makes this really difficult for madVR because both look identical to madVR. E.g. imagine you switch them around: madVR would never be able to notice! That somehow doesn't fully match my current device setup logic.

Any thoughts on this anyone?

Nope, from what I can tell It's just the fact it's switching to exclusive, tried a bunch of options with no effect. It's an Intel driver issue.
Please try disabling the refresh rate changer, just to be safe. The only change in the latest madVR build which I find likely to be related to this is that I've added a hack to make refresh rate changing work properly when entering FSE mode. So I really do wonder whether that's what's causing the delay...

And this definitely doesn't occur in v0.86.6, correct?

[ryrynz]

Please try disabling the refresh rate changer, just to be safe.
And this definitely doesn't occur in v0.86.6, correct?

Enabled or disabled, same deal.
Definitely no issue with 0.86.6.

[michkrol]

Correct.
Please try disabling the refresh rate changer, just to be safe.

It doesn't happen with 0.86.6, just double-checked. Disabling the display mode switcher doesn't help.

Checking the mode switcher changes, I've found how to get back the old behavior for one playback (active instance of madVR?), might help in debugging, do the following:

Enable diplay mode changer - set to change while going and leaving fullscreen
Enter a mode that would force switch as the only available
Go fullscreen - the refresh mode changes (as it should)
Leave fullscreen - the mode changes back (as it should)
Disable mode switcher
Go fullscreen (exclusive) - the switch is instantaneous as in v0.86.6

This works until the player/madVR is restarted. Hope it helps somehow.

[andybkma]

Well good news & bad news. Good news is I can confirm that "fixed: #30: ZoomPlayer got stuck in 'on top' mode after leaving FSE" seems to be working. Bad news is that I also have the delay now when going into FSE (not out of FSE). I have never had the refresh changer turned on and I am using the exact same settings as 86.5. So definitley something was introduced into 86.7 to cause the delay.

But going back to the good news... thanks for fixing the Bug 30 Zoom Player issue :-)

[Moragg]

Okay, so I think I've found the problem.

In FSE turning off the "Present Several Frames In Advance" massively screws up playback - dropped frames, at scene changes the last one "ghosts" a few seconds into the next scene, the image bounces all the time, and is generally unwatchable.
Turn it on however and playback is smooth as butter.

No other programs open, GPU load remains constant at 50%. I'm not sure how presenting a few frames early could have such a massive effect on performance.
With 1 frame in advance I get 12 frame drops per second.
With 2 in advance this drops to 0.
This is a 48fps video and my screen is 120Hz, if that makes any difference.
Also, without FSE I get ~16 drops per second - and playback is nowhere near as bad as when I turn off "present frames in advance" in FSE, just normal dropped frames.

[madshi]

Ok, will have to check whether I can isolate the problem with the FSE switch delay somehow.

In FSE turning off the "Present Several Frames In Advance" massively screws up playback - dropped frames, at scene changes the last one "ghosts" a few seconds into the next scene, the image bounces all the time, and is generally unwatchable.
Turn it on however and playback is smooth as butter.
Well, by turning "Present Several Frames in Advance" off you're practically going back to a rather old logic which madVR had used a long time ago. Some people are still using it because for some reason it works better for them. But as you found out yourself, having "Present Several Frames in Advance" turned on with a reasonably high number of frames produces better results for most users - especially on OSs newer than XP.

No other programs open, GPU load remains constant at 50%. I'm not sure how presenting a few frames early could have such a massive effect on performance.
With 1 frame in advance I get 12 frame drops per second.
With 2 in advance this drops to 0.
This is a 48fps video and my screen is 120Hz, if that makes any difference.
Also, without FSE I get ~16 drops per second - and playback is nowhere near as bad as when I turn off "present frames in advance" in FSE, just normal dropped frames.
Well, there you have it: FSE simply is the most reliable playback method. There's a reason why I have it enabled by default in the madVR settings - even though it comes with a number of usability disadvantages.

If your GPU supported Overlay mode, that would have been another thing worth trying. But if normal windowed mode simply doesn't run well on your PC (for whatever reason) you may have no other choice than to use FSE mode.

[sgraves66]

That sounds like a weird way to use madVR. I don't really know what to recommend here. The renderer window not fully filling the screen sounds like something that you should be able to fix yourself by using IVideoWindow::SetWindowPosition()? Not sure about the hidden status. In the worst case I guess you could use Detours (or some other API hooking solution) to hook ShowWindow() and related APIs to block madVR from making itself visible again? To be honest, I'm not really sure who makes the madVR window visible again, could also be Direct3D or the MS base classes on which madVR is built. Don't really know...

It's a bit odd, but I need a way to draw directly onto the video output in windowed-mode for OSD purposes and the UI is cross-platform, so no D3D for me. OpenGL surfaces also don't play nice with native child windows and they tend to disrupt the UI in general. ISampleGrabber is used for RGB24 capture until I have time to roll my own to convert NV12->RGB24 or perhaps implement a shader for NV12 conversion. IVideoWindow::SetWindowPosition() works intermittently, as well. Normal window positioning through IVideoWindow is just hit-or-miss for some reason and I assume it has something to do with the OpenGL rendering and event threads, but it honestly doesn't make a whole lot of sense to me. Specifying a parent window alleviates the issues. Thanks!

[Q-the-STORM]

Hmmmm... I'm not totally sure I understand what CRU does and how it affects madVR.

CRU is an easy way to do EDID overrides....
So if he can change the product ID with CRU, the monitors don't have an EDID block...

like you said, madVR wouldn't be able to notice if you switch identical monitors around, but theoretically madVR should be able to detect both displays... maybe it just ignores monitors that have the same Product ID, because like you said, they should run with the same settings....

though for calibration it would be good to be able to put in a different 3DLUT, since displays always differ...

But I guess atm you can already accomplish this by changing the product ID with CRU or any other EDID override...

[turbojet]

Well, if there's a 100% reliable way to reproduce this, and if the backbuffer queue is really the only problem, then you can create a bug entry in the madVR bug tracker for this. I can only do anything (if at all) if I can reproduce it, though. So do your best to create a good step-by-step guide that allows me to reproduce the problem on my PC. I can't promise that there is anything I can do about it, though. It must just be a limitation of normal windowed mode. That's why I added Overlay and FSE modes...

I suppose you did try to use a larger backbuffer queue and it didn't help?


Can you try encoding a source that's decoded by cuvid or quicksync while playing a video with frc on? That's a pretty constant drop in frames for me but it may take a few minutes to start happening. Otherwise would a log while it's happening help?

Overlay and FSE have limitations that make it impossible to use in certain situations. Larger backbuffer queue quickly jumps from 7-8/8 to 0/8.

[mindbomb]

madVR's IVTC needs to be manually enabled. Or you can leave it on all the time, but then you may have to manually disable it for true video content. If you can live with having to manually switch madVR's IVTC algorithm on/off once in a while then you don't need NVidia's IVTC. If you prefer to have everything done automatically, you can disable madVR's IVTC algorithm and use DXVA deinterlacing instead. Then it would make sense to turn NVidia's "inverse telecine" on. The disadvantage is that NVidia doesn't decimate. So 60i is converted to 60p instead of 24p. So you'll still have the 3:2 pulldown judder. This problem does not happen with madVR's IVTC algorith, which properly decimates to 24p.


More or less correct. However, the problem is not what madVR knows or doesn't know. The problem is that DXVA can't really do decimation, technically.


wait, I've seen my fps go to 23.976 fps on telecined content without using madVR's film mode. I presumed this was the work of nvidia's ivtc, and subsequently had issues with judder in the sense that the refresh rate changer chose 59.94 because the source filter was reporting 29.97.