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

cyberbeing

26th April 2011, 21:51

24p/30p?? What does such kind of content come from? Are we talking about NTSC DVDs? If so, they are likely not 24p/30p, but instead 60i. Deinterlaced properly this might end up as either 24p or 60p.
It's hybrid interlaced content from TV and DVDs (particularly of Japanese origin). It happens when native 24p and native 30p content is mixed in an interlaced stream. For example, a show that is mostly 24fps, would have 30fps commercials, credits, and cgi mixed in mid-stream. It can get much worse than that, but that is the basic idea. The only proper way to maintain smoothness for such content after deinterlacing, is creating 24p/30p (or potentially 24p/60p) VFR clips.

I need to use a 120Hz refresh rate for such clips for perfect smoothness with madVR. This is especially important when using Reclock, or you will have a short skip in the audio every time the frame-rate changes (it flushes the audio buffer whenever it changes mode from adaption to/from non-adaption).

Well, you're using very high refresh rates, combined with XP (IIRC) and NVidia. That's a really very bad combination for exclusive mode, it seems. My impression is that ATI handles this situation better. But I'm not really sure since most of you high-refresh-guys seem to use NVidia, for whatever reason...
The ability to set custom resolutions and timings with NVIDIA CPL probably has something to do with it.

Do you have to set the queue to 14 to achieve good results? Or did you do that just for peace of mind?
Peace of mind I guess. It stays stable with 14 queues at 14/14, so why not. Setting it any higher causes it to fluctuate between 14 and 16. The new mode is smoother for 24p on 60Hz than previously, and I get no presentation glitches or anything, even with no flushing. I haven't tried a lower number of queues or the 'glitch hack'.

The clock deviation measurement consists of just a few floating point calculations once every second. I don't see how that could result in any latency issues.

Any ideas of something within madVR which only starts after 3-4 seconds into playback?

I was thinking that maybe madVR querying the HPET or Multimedia Timers constantly (QueryPerformanceCounter?) could be causing it. (http://msdn.microsoft.com/en-us/windows/hardware/gg463347.aspx)
A timer malfunction could also explain it being ISR latency instead of DPC.
Exclusive Interrupts
In addition to generating independent interrupts, each comparator must have a unique (non-shared), edge-triggered interrupt in LegacyIRQRouting mode. This is required because timer interrupts are used extensively during regular operations, and processing the interrupt service routine (ISR) of a shared interrupt is more expensive than processing an exclusive interrupt. I figure it could just be a platform issue with Intel and the P55 chipset on Win7 x64. The only other possibility is some ATI driver flaw, which only shows when using madVR, but you can't reproduce the problem (?). All I know is the problem still exists even with audio hardware disabled, and there is no increase in latency with other D3D applications and renderers, but all versions of madVR (even the really really old 0.1x ones) trigger the problem, so the code must have existed in the your initial madVR codebase.

Either way, the increase, though significant (+ 500 µs), doesn't really cause any performance or drop-out problems since that PC almost never goes above ~50 µs even under load (except with madVR after 4 seconds).

yesgrey

26th April 2011, 22:18

Hmmmmm... Weird. Are you using custom flush options?
Yes. All set to don't, but you said that when using the glitch hack you would internally activate the flush & wait, so I didn't bother to change it.

Do you get the same results with the default flush options (flush, flush & wait (sleep), don't, don't)?
With the glitch hack yes.

Without the glitch hack it got worse. I got 4 glitches (only at beggining) instead of 1 with everything set to "don't"

Would a log help?

sneaker_ger

26th April 2011, 22:38

I can't do any Nvidia tests for the time being, but my "final" tests with with 0.58 on Win 7 x64:
9200M GS with and without glitch hack, 270.61 drivers, standard settings except all scaling to bilinear, 24p@60Hz:
glitches

GTX 560 Ti with and without glitch hack, 266.66 drivers, standard settings, 24p@60Hz:
glitches

ajp_anton

26th April 2011, 23:16

Smo-mo in MPC-HC isn't smooth at all, in both windowed and exclusive. Can this be fixed?
What is "Smo-mo"? I've no idea what you're talking about...
Slow motion. Press ctrl+down (i think that's the default key) in MPC-HC. I have no idea how this is achieved and if the jerkiness is because of MPC or madVR...

iSunrise

27th April 2011, 00:22

Thanks madshi for 0.58.

I´ve done some tests with and without the glitch hack enabled and I must say that the results seem very good with the glitch hack turned on. I´ve mainly done tests with 23.976fps, 24fps and 29.970fps@60Hz.

Without the glitch hack enabled the presentation glitches always increase throughout the presentation. When the glitch hack is enabled the presentation glitches stay at 0 (zero glitches), no matter what content I throw at madVR. So, whatever you did, something seems to be working a lot better than without the hack enabled. At least that´s how I interpret these results.

The only other thing that I saw is that the render queue drops to 2-3/8 instead of 7-8/8 when the glitch hack is enabled. But that doesn´t seem to be a problem at all, since everything is perfectly smooth.

My exclusive mode settings just for reference:
1, don´t flush, don´t flush, don´t flush, don´t flush

I have an NVIDIA GTX260-216 and I´m using the Nvidia Quadro 270.61 drivers on Vista x64.

jdl

27th April 2011, 00:54

According to the log madVR doesn't go fullscreen because of this:

madVR window [madVR] "madVR" {1280,0,3200,1080}
covered by explorer.exe window [Shell_TrayWnd] {-2,1022,1282,1052}

The tray window (which I think is the window where all the tray icons and the clock etc are in) seems to overlap the madVR rendering window. Please double check your dual monitor setup. It seems that your primary and secondary monitors overlap ever so slightly?

Thanks again for looking at this. I've had a chance to do a little more experimentation and it seems this is a primary/secondary display issue. When I set up MPC-HC to launch on the primary display, it goes into exclusive mode as it should. When it's on the secondary display, it starts out in windowed mode. I have my primary display set up on my LCD monitor, with my projector the secondary display.

I don't see any overlap between the displays that I can find.

Hypernova

27th April 2011, 01:37

You might choose to deinterlace it before putting it into a MKV, resulting in 24p/30p mixed content - i actually have seen MKVs just like that of those DVDs.

I also have some sample 24p/30p MKVs of some Animes. Not sure why they are like that, but i got them from people reporting frame rate reporting bugs in LAV Splitter.
Anime always does the weirdest things to their content..

FWIW, I've seen that once in Air BD release. I think the reason is the studio re-animate the op but not the show itself. Also, the release timeframe was from fairly early era of BluRay, so I think they're confused as well.

madshi

27th April 2011, 07:38

This is an HP Envy 17 3D with Radeon HD6850M. I have the same issue with the latest drivers officially supported by HP (8.800.8.100) as well as the drivers shipped with Catalyst 11.3 (8.831.2.0)

The 11.4 Catalyst will supposedly make sweeping changes to the driver when released, however no Envy owners have been able to get the 11.4 preview release to work. If you'd like we can revisit this topic again whenever there are newer drivers released that work on this laptop.
Well, maybe I can find a fix, you can retry future madVR versions. There will not be a fix in the very next build, however.

Peace of mind I guess. It stays stable with 14 queues at 14/14, so why not. Setting it any higher causes it to fluctuate between 14 and 16. The new mode is smoother for 24p on 60Hz than previously, and I get no presentation glitches or anything, even with no flushing. I haven't tried a lower number of queues or the 'glitch hack'.
Yeah, another confirmation that AMD/ATI cards seem to have less glitch problems compared to NVidia.

Any ideas of something within madVR which only starts after 3-4 seconds into playback?
Not really.

I was thinking that maybe madVR querying the HPET or Multimedia Timers constantly (QueryPerformanceCounter?) could be causing it. (http://msdn.microsoft.com/en-us/windows/hardware/gg463347.aspx)
I'm calling QueryPerformanceCounter, but I'm doing that all the time, not only after 4 seconds. Also I think EVR-Custom is calling that, too.

Yes. All set to don't, but you said that when using the glitch hack you would internally activate the flush & wait, so I didn't bother to change it.

Without the glitch hack it got worse. I got 4 glitches (only at beggining) instead of 1 with everything set to "don't"

Would a log help?
So the problem is not the glitch hack, but something else? Can you please tell me which release worked without glitches and which exact madVR version introduced the glitches for you?

I can't do any Nvidia tests for the time being, but my "final" tests with with 0.58 on Win 7 x64:
9200M GS with and without glitch hack, 270.61 drivers, standard settings except all scaling to bilinear, 24p@60Hz:
glitches

GTX 560 Ti with and without glitch hack, 266.66 drivers, standard settings, 24p@60Hz:
glitches
Is that worse than before? 24p@60Hz seems to have always been problematic with NVidia. Were you able to play that without glitches with an older v0.5x version?

Slow motion. Press ctrl+down (i think that's the default key) in MPC-HC. I have no idea how this is achieved and if the jerkiness is because of MPC or madVR...
Hmmmm... Seems to work ok for me. Do you get dropped/delayed frames or glitches in the madVR OSD? Do you get smoother playback with other renderers? You're extremely short on details.

I´ve done some tests with and without the glitch hack enabled and I must say that the results seem very good with the glitch hack turned on. I´ve mainly done tests with 23.976fps, 24fps and 29.970fps@60Hz.

Without the glitch hack enabled the presentation glitches always increase throughout the presentation. When the glitch hack is enabled the presentation glitches stay at 0 (zero glitches), no matter what content I throw at madVR. So, whatever you did, something seems to be working a lot better than without the hack enabled. At least that´s how I interpret these results.

The only other thing that I saw is that the render queue drops to 2-3/8 instead of 7-8/8 when the glitch hack is enabled. But that doesn´t seem to be a problem at all, since everything is perfectly smooth.

My exclusive mode settings just for reference:
1, don´t flush, don´t flush, don´t flush, don´t flush

I have an NVIDIA GTX260-216 and I´m using the Nvidia Quadro 270.61 drivers on Vista x64.
Glad to hear that!

Thanks again for looking at this. I've had a chance to do a little more experimentation and it seems this is a primary/secondary display issue. When I set up MPC-HC to launch on the primary display, it goes into exclusive mode as it should. When it's on the secondary display, it starts out in windowed mode. I have my primary display set up on my LCD monitor, with my projector the secondary display.

I don't see any overlap between the displays that I can find.
Weird. Try moving the primary monitor down a bit so that the taskbar is *below* the bottom of the secondary monitor. That might work around the issue. It seems that a few pixels of the taskbar are covering the secondary monitor. Don't know why...

prophete

27th April 2011, 11:00

Can anybody confirm that this problem was introduced with v0.57 and didn't occur in versions older than v0.57? My impression was that the problem occurred all the time. If it really was introduced in v0.57, maybe I can fix it.

I use madVR since 0.51 or 0.52 and before the 0.57, I never see this bug. When I have install 0.57, I haven't change any other programs...

Since, I have update mon mpc-hc and ffdshow but the bug still present. If I use EVR and I test videos, I have never the problem but when I put madVR, the problem is back.

Somedays I don't have the bug and another days I have it on every videos I launch :(.

madshi

27th April 2011, 11:02

I use madVR since 0.51 or 0.52 and before the 0.57, I never see this bug. When I have install 0.57, I haven't change any other programs...

Since, I have update mon mpc-hc and ffdshow but the bug still present. If I use EVR and I test videos, I have never the problem but when I put madVR, the problem is back.

Somedays I don't have the bug and another days I have it on every videos I launch :(.
I believe you. But every PC behaves differently. So I need others to confirm your experience before I take the time to look into it.

madshi

27th April 2011, 11:41

madVR v0.59 released

http://madshi.net/madVR.zip

* added D3D11 presentation path
* renamed glitch hack to "use a separate device for presentation"
* added option to activate D3D11 presentation path
* switched and renamed option "present only one frame at a time"
* added tweak option "run presentation in a separate thread"
* added tweak option "limit rendering times to avoid glitches"
* added option "restore original display mode when media player closes"
* added option "treat 25p movies as 24p (requires Reclock)"
* added detection for "Windows Key" press -> switch out of exclusive mode
* fixed: having only one mode in the display mode switcher didn't work
* fixed: when entering fullscreen, sometimes the seekbar incorrectly showed up
* fixed: changing refresh rate behind madVR's back resulted in a freeze
* fixed: ZoomPlayer froze when moving to secondary monitor fullscreen playback
* a couple more minor changes and bugfixes
On the quest for glitch free playback I found a way to *present* the frames using Direct3D11 while still rendering in Direct3D9. Direct3D11 has a couple of features Direct3D9 does not have, which seems to help reducing the glitch problem. At least it does on my PC. Since this is still a somewhat experimental new feature I've disabled it by default. But for me the Direct3D11 presentation seems to produce the best results, especially when the display refresh rate is higher than the movie framerate. Please give it a try and report back!

There's one disadvantage to the Direct3D11 solution, unfortunately: Switching between windowed and exclusive mode is not as nice as with Direct3D9. It still works, but seems to be a bit slower and uglier. Maybe I can improve that in a future version, or maybe not.

I've also added 2 more tweak options which may eventually help reducing the glitches further. Please check these out, too, but it seems that on my PC, these options don't really help much, when using Direct3D11. They actually make things worse sometimes. Still, I left these options in v0.59 for you to play with.

Finally, as requested by many people, madVR can now restore the original display mode when the media player closes.

leeperry

27th April 2011, 11:47

w00t, lot of fixes/new features to try. :thanks:

madshi

27th April 2011, 11:50

ajp_anton

27th April 2011, 11:56

leeperry

27th April 2011, 11:57

Yeah, but you're still on XP, aren't you? Of course D3D11 is not available for XP. It seems that we're at a point where upgrading from XP to Windows 7 might really starting to make sense for some people... ;) That said, since you're happy with windowed mode right now, upgrading would of course be a risk. So I'd wait for other high-refresh-rate people to chime in with their D3D11 madVR experience before even starting to think about upgrading...
yup, XP..and the old FSE path works damn fine for me.

I don't see what DX11 will do for me? headaches mostly? :D

The day you will support full 10bit, and I will have a 10bit display, I'll think about it.

The 2 options under "present several frames in advance" don't do anything on XP either?

BTW:
1) external refresh rate switching works perfectly now, thank you \o/
2) but the window key acts strangely...the first time I tried, I got the start menu on top as expected...but the other 20 times I tried afterwards, it only blinked for a split second and mVR immediately went back to FSE. Maybe PotP is enforcing "always on top"....so I thought it might be good that you actually make the taskbar on top when we press the window key?

PS: w/ the new path, presentation glitches increment VERY slowly now...it used to be a lot steadier.

ajp_anton

27th April 2011, 12:01

pirlouy

27th April 2011, 12:08

Is there somebody to write a script which would allow an easy update ?
I click on this script (in madVR directory), it downloads and unzip files in directory after UAC prompt.

If someone is interested... :D

Aleq

27th April 2011, 12:16

Madshi, thanks a million for another quick update

noee

27th April 2011, 12:24

Some quick feedback. On my desktop mon (60Hz only), I can get FSE to work with the DX11 path. But when I play back on my secondary mon (23.976Hz), with the DX11 path, the playback stops after about 10 seconds. The player is not locked and is responsive, it's just that the screen is frozen and there's no playback activity. Happens with both Mc16 and MPC-HC. Tried toggling the various options, same results.

Could be the card? Is it necessary to have a DX11 capable card? Dumb question?

Edit: Take it back. It seems even in the old path, after few minutes of playback, the player just stops playing. At that point, I can start playing again just by hitting play in the player.

Also, a couple of things to note in Dual-mon situations:
1. It's not necessary to go to windowed mode when the Win key is hit when playback is on the second monitor and desktop is on the first.
2. WHen playback is on the second monitor and I run my mouse to the bottom of the first monitor, the seek bar becomes visible on the playback mon.

Mr Alpha

27th April 2011, 13:09

madVR 0.59 crashes mpc-hc when switching to full screen exclusive mode. With the DX11 path the crash happens immediately, and with the DX9 path the crash happens after ~40 seconds.

janos666

27th April 2011, 13:31

When I saw D3D11 I thought you started to use this API because it makes it easier to support 10(+?) bit output.

(By the way... Is it even possible to output 12-bit from the current DX11 VGA cards? I know that in DX11, you can send even 16 bit/color to the LUT but how many bits can go out on the HDMI cable with 1920x1080p24? The cable has the bandwidth for many bit/colors with this refres rate but what about the VGA...? Not a big thing at all, I am just wondering...)

@noee
I don't think you need a DX11 card but an OS which supports DX11 and a card which is supported by DX11 (DX9 and later hardware).
A DX11 card would be necessary if he used hardware features which are only available on DX11 compatible hardwares.
So, I think an updated Vista + a Geforce FX or Radeon 9800 is "fine" (they are too slow for FullHD movies but support SM2.0)

madshi

27th April 2011, 13:35

I'm having trouble getting into exclusive mode. Sometimes it works, but mostly it *immediately* goes back to windowed with just a quick flash in fullscreen.
MPC-HC says "Focus lost to: mpc-hc.exe - madVR".
Can't seem to reproduce with the debug build.
Happens even after restoring to default settings. 0.59. No problems with 0.58.
Hmmmmm... Does this test build fix the problem?

http://madshi.net/madVR59b.zip

The 2 options under "present several frames in advance" don't do anything on XP either?
Yes, they do.

2) but the window key acts strangely...the first time I tried, I got the start menu on top as expected...but the other 20 times I tried afterwards, it only blinked for a split second and mVR immediately went back to FSE. Maybe PotP is enforcing "always on top"....so I thought it might be good that you actually make the taskbar on top when we press the window key?
I'm just switching to windowed mode. If you have disabled the 3 second delay then maybe that causes madVR to go back to exclusive mode immediately if the start menu doesn't pop up fast enough. Try with the 3 second delay. Maybe that works better?

Some quick feedback. On my desktop mon (60Hz only), I can get FSE to work with the DX11 path. But when I play back on my secondary mon (23.976Hz), with the DX11 path, the playback stops after about 10 seconds. The player is not locked and is responsive, it's just that the screen is frozen and there's no playback activity. Happens with both Mc16 and MPC-HC. Tried toggling the various options, same results.

Could be the card? Is it necessary to have a DX11 capable card? Dumb question?

Edit: Take it back. It seems even in the old path, after few minutes of playback, the player just stops playing. At that point, I can start playing again just by hitting play in the player.
Weird!!! Can I have a log, please? Please don't restart the playback. Just wait until it stops, then wait another 5-10 seconds, then close the media player immediately. Thanks.

Also, a couple of things to note in Dual-mon situations:
1. It's not necessary to go to windowed mode when the Win key is hit when playback is on the second monitor and desktop is on the first.
2. WHen playback is on the second monitor and I run my mouse to the bottom of the first monitor, the seek bar becomes visible on the playback mon.
Yep, right on both. Will fix that.

madVR 0.59 crashes mpc-hc when switching to full screen exclusive mode. With the DX11 path the crash happens immediately, and with the DX9 path the crash happens after ~40 seconds.
Oh boy, there are more problems with v0.59 than I anticipated! I take it you're using Windows 7? Which GPU? Can I have a log, please? It will probably not help (rarely does for crashes), but having a log is better than having nothing.

Can you also try the special build linked to above? Thx.

When I saw D3D11 I thought you started to use this API because it makes it easier to support 10(+?) bit output.

(By the way... Is it even possible to output 12-bit from the current DX11 VGA cards? I know that in DX11, you can send even 16 bit/color to the LUT but how many bits can go out on the HDMI cable with 1920x1080p24? The cable has the bandwidth for many bit/colors with this refres rate but what about the VGA...? Not a big thing at all, I am just wondering...)
10bit has nothing to do with my reasons to go D3D11.

12bit output is not possible, there's no Direct3D support for that. You can use either 10bit or you can directly go 16bit, which will also give you extended gamut support. But with 16bit you have to render in linear light and trust in that the GPU/drivers convert that to gamma light properly. Which is a design catastrophe, IMHO. Someone at Microsoft should get fired for such a stupid decision. GPU manufacturers don't exactly have a track record at getting things right. IMHO the only useable alternatives right now are 8bit and 10bit output.

SamuriHL

27th April 2011, 13:41

Won't get to test this until I get home later. Thanks for the option to return to the original refresh rate! That is a very welcome change.

noee

27th April 2011, 13:57

Weird!!! Can I have a log, please? Please don't restart the playback. Just wait until it stops, then wait another 5-10 seconds, then close the media player immediately. Thanks.

Logs emailed. I think I found the issue, it's the Glitch/Hack (renamed now). With it on, regardless of D3D9 or D3D11, the player just stops.

Another weird thing, as I was cycling thru the options trying to find a working path, I could've sworn that I saw, at one point in the stats, the msg "fullscreen exclusive mode (old path)". I've now yet to see it since. Am I imagining things?

BTW, I've found the "sweet spot" once again for FSE:

4 frames in advance
present in sep thread
flush/flush/don't/don't

use separate device... [off]

janos666

27th April 2011, 14:07

12bit output is not possible, there's no Direct3D support for that. You can use either 10bit or you can directly go 16bit, which will also give you extended gamut support. But with 16bit you have to render in linear light and trust in that the GPU/drivers convert that to gamma light properly. Which is a design catastrophe, IMHO. Someone at Microsoft should get fired for such a stupid decision. GPU manufacturers don't exactly have a track record at getting things right. IMHO the only useable alternatives right now are 8bit and 10bit output.

Not necessarily.

May be the idea is that the VGA LUT receives the linear input and it outputs the gamma corrected 8/10/12/16 bit values (the highest bit depth which is reported by the EDID). You always have gamma correction anyway if you calibrated your display with this LUT, so the default VGA LUT won't be linear anymore but designed to produce gamma 2.2, that's all (and at least the Radeon cards apply dithering on the output and reach 10 bit/color effective precision with 8-bit devices. So, the dithering noise could be gamma corrected too...) Oh, and it would make it easier to apply 3D color corrections by the VGA card (it could read out the gamut coordinates from the EDID and apply the gamut mapping on the linear RGB values).

sneaker_ger

27th April 2011, 14:14

Is that worse than before? 24p@60Hz seems to have always been problematic with NVidia. Were you able to play that without glitches with an older v0.5x version?

I had no glitches when running the 0.57 glitch hack version on the 9200M GS on the half hour long short test I ran. Maybe just a coincidence? Can't test anymore, sadly.

to 0.59 on HD 5850 Win7 x64:
If I activate "use a separate device for presentation" but not D3D11 I can't go into fullscreen mode. If I activate D3D11 I can go into fullscreen, but after I go back into window mode the "minimize", "maximize" and "close" buttons of MPC-HC are gone.

madshi

27th April 2011, 14:28

Logs emailed. I think I found the issue, it's the Glitch/Hack (renamed now). With it on, regardless of D3D9 or D3D11, the player just stops.
I can see that in both your logs you have the option "run presentation in a separate thread" activated, which is not the default setting. Can you please try to deactivate this option? Does the Glitch Hack (now renamed) still result in the player stopping that way? If so, can you please send me a log from that situation? Thx.

Another weird thing, as I was cycling thru the options trying to find a working path, I could've sworn that I saw, at one point in the stats, the msg "fullscreen exclusive mode (old path)". I've now yet to see it since. Am I imagining things?
That's the old exclusive mode, which you can get if you uncheck the option "present several frames in advance".

Not necessarily.

May be the idea is that the VGA LUT receives the linear input and it outputs the gamma corrected 8/10/12/16 bit values (the highest bit depth which is reported by the EDID). You always have gamma correction anyway if you calibrated your display with this LUT, so the default VGA LUT won't be linear anymore but designed to produce gamma 2.2, that's all (and at least the Radeon cards apply dithering on the output and reach 10 bit/color effective precision with 8-bit devices. So, the dithering noise could be gamma corrected too...) Oh, and it would make it easier to apply 3D color corrections by the VGA card (it could read out the gamut coordinates from the EDID and apply the gamut mapping on the linear RGB values).
Whatever their aim is with this, I do not agree with it. I do not use the VGA LUT and I don't want the GPU/drivers to mess around with my rendering output. It is not acceptable that Windows doesn't allow me to define the exact output.

I had no glitches when running the 0.57 glitch hack version on the 9200M GS on the half hour long short test I ran. Maybe just a coincidence? Can't test anymore, sadly.
Why can't you test that, anymore?

to 0.59 on HD 5850 Win7 x64:
If I activate "use a separate device for presentation" but not D3D11 I can't go into fullscreen mode. If I activate D3D11 I can go into fullscreen, but after I go back into window mode the "minimize", "maximize" and "close" buttons of MPC-HC are gone.
Weird. Have you tried the special build linked to earlier? Does that allow you to go into exclusive mode when not using D3D11? If not, please upload a log for me from that situation (failure to go to exclusive mode). Please create the log with the OSD (Ctrl + J) turned on. Thanks.

Mark_A_W

27th April 2011, 14:34

madshi, you asked about my fullscreen windowed mode results: with 0.57 and earlier, I would get inconsistent results. So far with 0.58 I have had excellent, consistent results.

With 0.59...

Exclusive was working PERFECTLY. As smooth as silk, no drops, no delayed....but just ONCE. It was using the "old path" - it said it in brackets in the description in the OSD. But only once, every other time I get exclusive mode failed. Once I got "madVR reports:-creating gpu 3dLUT volume texture failed, and another "-creating Direct3D device failed 8876086c) when I tried the D3D11 (old path).

All the "new path" present several frames in advance settings result in glitches, both visible and reported (and drop frames).

Fullscreen windowed mode seems to work as well as 0.58, with or without the D3D11 setting checked (does it do anything in windowed?). Backbuffers at one - works for me.

W7 x64, Ati 4850, 95.907hz interlaced, 23.976fps source material, reclock fully enabled.

madshi

27th April 2011, 14:46

madshi, you asked about my fullscreen windowed mode results: with 0.57 and earlier, I would get inconsistent results. So far with 0.58 I have had excellent, consistent results.
Ah, ok.

Exclusive was working PERFECTLY. As smooth as silk, no drops, no delayed....but just ONCE. It was using the "old path" - it said it in brackets in the description in the OSD. But only once, every other time I get exclusive mode failed. Once I got "madVR reports:-creating gpu 3dLUT volume texture failed, and another "-creating Direct3D device failed 8876086c) when I tried the D3D11 (old path).

All the "new path" present several frames in advance settings result in glitches, both visible and reported (and drop frames).
"D3D11 (old path)" doesn't make sense. You can use D3D11 only with the new path. I'm not sure about your report. You say you're getting exclusive mode failed and that you get glitches. Does that mean you get glitches after the exclusive mode failed? Or did exclusive not fail every time, after all, and *then* you got glitches (while in exclusive mode)? I'm not sure if you ever got D3D11 working in exclusive mode?

ajp_anton

27th April 2011, 14:50

Hmmmmm... Does this test build fix the problem?Yes, thank you.

sneaker_ger

27th April 2011, 14:52

Why can't you test that, anymore?

Not related to madVR.

Weird. Have you tried the special build linked to earlier? Does that allow you to go into exclusive mode when not using D3D11?

Just tested it, and yes, it does.

noee

27th April 2011, 14:53

Can you please try to deactivate this option? Does the Glitch Hack (now renamed) still result in the player stopping that way? If so, can you please send me a log from that situation?

Okay, disabled the separate thread present and enabled the use separate dev and D3D11, still stops. Log emailed.

Hprd

27th April 2011, 15:01

Well i have some good news and bad news with .59. Firstly the bad stuff. Unless i turn on dx11, i get the same issue as ajp_anton is getting. Or basically it goes back to windowed right away, and rarely stays in FSE. With dx11 on, it works perfectly everytime, but when i goto windowed, MPC-HC's exit/minimize etc buttons (forget what the general term for these is...) are gone, and i have to restort to rick clicking on mpc-hc on the taskbar to close the video. Also most of the time exit from FSE the video is in fullsceen mode (fills the screen of course i mean), and doesn't go to the "auto" size that i have set in mpc-hc defaultly.

Good news is though, that with dx11 plus the 2 new hacks, or w/e you'd call them, for the new FSE (run in seperate thread, limit rendering times) i now have zero glitches/dropped frames etc. as far as i can tell from limited testing. Strangely though, there were still some (or about the behavior with the new hacks turned off, or specifically the limit one, as the other alone didn't completely fix it) on 720p (or basically any video lower than native res that madvr then had to upscale, in which then it would switch to 1080p23 or 30 unless I specified in the filename otherwise) 30fps videos played back at 1200p60.

I then found that if i turned the auto resolution changing off, and didn't put "60p" in the filename (madvr showed that it was 60fps when i did, the normal actual fps when i didn't, which is how it works of course) i got the same playback (5-6/10 as compared to 6-7/10 on the presentation cue when madvr showed the file was 60fps, which of course then there would be glitches) as the 1200p files i made (and 24p videos at 48p as well i found were fine, probably due to the lower framerate not being as hard to render, or well, to get it to goto 1200p48, i put 24p in the filename... so i'd imagine if i could get madvr to see it as 48p, i'd do the same thing, as b4 it would glitch).

Also, the option (when resolution changing is on) to go back to the original resolution works perfectly :)

I also confired subjectively what the OSD was showing by playing one of the "Frame Rate Test" files that somebody liked to here recently. And with the 29.970 fps one at 60 fps, playback was more or less perfectly smooth ;) (aside of course from the inevitable frame repeats once and a while, which decreased the longer i played the video, or about what the OSD showed it seemed)

iSunrise

27th April 2011, 15:03

Thanks for 0.59 madshi.

While 0.58 gave me excellent results with the D3D9 path and the glitch hack enabled (and also the old FSE path), 0.59 is giving me some headaches.

It seems that 0.59 introduces at least one major bug that makes testing a bit complicated, because after some testing, I realized that it only appears in MPC-HC, whereas PotPlayer works perfectly fine.

MPC-HC (major)
- Going fullscreen does only work when the new D3D11 path and present frames in advance is enabled. Otherwise the screen flickers for a second and after the flicker is gone I´m still in windowed mode. With PotPlayer (my main player) this works perfectly fine, though. No problems whatsoever.

D3D11 (MPC-HC and Potplayer)
- When switching back from fullscreen to windowed the media player doesn´t return to the native (windowed) resolution of the movie, but instead it tries to display the movie in the fullscreen resolution in windowed mode. This works perfectly fine with the D3D9 path and the old FSE path.

The new D3D11 path does seem to be problematic in it´s current state. From limited testing I have to say that whatever option I checked, I can´t make the D3D11 work as good as the D3D9 path. I will always get presentation glitches, whereas D3D9 and the glitch hack works perfectly without any presentation glitches.

noee

27th April 2011, 15:12

fyi, per my previous test, disabling D3D11, player does not stop, all is well.

sneaker_ger

27th April 2011, 15:17

I'm calling QueryPerformanceCounter, but I'm doing that all the time, not only after 4 seconds. Also I think EVR-Custom is calling that, too.

I also had huge problems with EVR-CP on my Nvidia hardware, and I don't think I'm alone on that one. Vanilla EVR on the other hand worked just fine.
Maybe it's worth investigating?

leeperry

27th April 2011, 15:19

I'm just switching to windowed mode. If you have disabled the 3 second delay then maybe that causes madVR to go back to exclusive mode immediately if the start menu doesn't pop up fast enough. Try with the 3 second delay. Maybe that works better?
indeed! could you please enforce the 3" delay when pushing the windows key please?

and you haven't answered as to why DX11 might be worth the upgrade from XP to W7...I'm still wondering :o

sneaker_ger

27th April 2011, 15:23

indeed! could you please enforce the 3" delay when pushing the windows key please?

and you haven't answered as to why DX11 might be worth the upgrade from XP to W7...I'm still wondering :o

I don't think it has anything to do with any features - more likely a desperate attempt to get rid of the glitching problems.

madshi

27th April 2011, 15:45

to 0.59 on HD 5850 Win7 x64:
If I activate "use a separate device for presentation" but not D3D11 I can't go into fullscreen mode. If I activate D3D11 I can go into fullscreen, but after I go back into window mode the "minimize", "maximize" and "close" buttons of MPC-HC are gone.
How about glitches? Still there or gone for you with 0.59 / D3D11?

Okay, disabled the separate thread present and enabled the use separate dev and D3D11, still stops. Log emailed.
In the log it seems that until 25 seconds after playback everything is fine. And then at exactly 25 seconds MPC-HC officially stops playback. There's even a "Stop" OSD messages sent to madVR, so MPC-HC behaves as if you actually pressed the Stop button.

Does that make any sense to you?

Well i have some good news and bad news with .59. Firstly the bad stuff. Unless i turn on dx11, i get the same issue as ajp_anton is getting. Or basically it goes back to windowed right away, and rarely stays in FSE.
Try the special build I linked to earlier, that fixed it for ajp_anton.

Good news is though, that with dx11 plus the 2 new hacks, or w/e you'd call them, for the new FSE (run in seperate thread, limit rendering times) i now have zero glitches/dropped frames etc. as far as i can tell from limited testing.
Do you really need those "2 new hacks"? What happens if you keep them both disabled? Do you still have glitches then with, even with dx11?

While 0.58 gave me excellent results with the D3D9 path and the glitch hack enabled (and also the old FSE path), 0.59 is giving me some headaches.

It seems that 0.59 introduces at least one major bug that makes testing a bit complicated, because after some testing, I realized that it only appears in MPC-HC, whereas PotPlayer works perfectly fine.

MPC-HC (major)
- Going fullscreen does only work when the new D3D11 path and present frames in advance is enabled. Otherwise the screen flickers for a second and after the flicker is gone I´m still in windowed mode. With PotPlayer (my main player) this works perfectly fine, though. No problems whatsoever.
Please try the special build I linked to earlier, which seems to fix this problem.

The new D3D11 path does seem to be problematic in it´s current state. From limited testing I have to say that whatever option I checked, I can´t make the D3D11 work as good as the D3D9 path. I will always get presentation glitches, whereas D3D9 and the glitch hack works perfectly without any presentation glitches.
That's quite disappointing. And a bit surprising. Which display refresh rate, movie framerate, GPU and OS are you testing with? Just to make sure, with the default settings (D3D11 new exclusive mode turned *on*, present thread and limit rendering tweak options turned *off") you have glitches?

fyi, per my previous test, disabling D3D11, player does not stop, all is well.
I'm confused. Earlier you reported that the problem occurred with D3D9, too?

indeed! could you please enforce the 3" delay when pushing the windows key please?
You want me to enforce a delay even though you explicitly turned it off? I'm sorry, but this is getting very complicated. Why don't you simply turn the delay back on? That's the recommended default setting, anyway...

and you haven't answered as to why DX11 might be worth the upgrade from XP to W7...I'm still wondering :o
Because running high refresh rates in exclusive mode with D3D9 is problematic.

leeperry

27th April 2011, 15:49

You want me to enforce a delay even though you explicitly turned it off? I'm sorry, but this is getting very complicated. Why don't you simply turn the delay back on? That's the recommended default setting, anyway....
coz I never use right-click menus...the only thing I do is use PotP's bottom transport bar, and it works flawlessly w/o the 3" delay. Anyway, nevermind...I can always CTRL+ALT+DEL when PotP's frozen, as I always did ;)
Because running high refresh rates in exclusive mode with D3D9 is problematic.
the old rendering path works fine on XP in 89.91/96Hz..just please don't ditch it :o

Hprd

27th April 2011, 16:02

Hmm well with 59b, i get glitches no matter what i try now, lol :confused:, so i put the .ax file from .59 back in, and it's perfect again. With 59b it switches with dx11 on much faster than on 59, or even without dx11 on, on 59b (which of course works fine with it off). Performance, as per glitches, was about the same with either mode on 59b. I suspect dx11 mode is broken somehow on 59b, or that's what it's acting like...

Also it seems to be just the limit render times hack that fixes it (doesn't seem to be JUST dx11 then obviously), with it off, or with just the other one on it still glitches. I'm just going to leave them both on, as it seems to have no ill effects.

noee

27th April 2011, 16:02

Does that make any sense to you?

No, it does not. Might be time for a reboot and some more testing....

I'm confused. Earlier you reported that the problem occurred with D3D9, too?

Yes, in that scenario, I also had the "run presentation in sep thread" enabled.

iSunrise

27th April 2011, 16:04

Please try the special build I linked to earlier, which seems to fix this problem.
Indeed, that fixed it. Thanks.

That's quite disappointing. And a bit surprising. Which display refresh rate, movie framerate, GPU and OS are you testing with? Just to make sure, with the default settings (D3D11 new exclusive mode turned *on*, present thread and limit rendering tweak options turned *off") you have glitches?
Yes. Movies are 23.976fps, 24fps and 29.970fps at a 60Hz display refresh and an Nvidia GTX260-216 on Vista x64. I just have to enable the "use D3D11 for presentation" switch, all other tweaks are always disabled, and the glitches are there. Without that option, no glitches at all. That´s perfectly reproducible every time. The 2 additional switches don´t solve that, unfortunately.

robpdotcom

27th April 2011, 16:11

* added detection for "Windows Key" press -> switch out of exclusive mode

Thanks for this. I was thinking of asking for a keyboard shortcut that would do basically the same thing.

BTW: I have the 3 second delay turned off, and it still works fine in MPC-HC.

madshi

27th April 2011, 16:19

Hmm well with 59b, i get glitches no matter what i try now, lol :confused:, so i put the .ax file from .59 back in, and it's perfect again.
That's weird. In 59b I've just changed something which should affect the change from windowed to exclusive mode. It should not affect glitches (except maybe directly after the switch).

Also it seems to be just the limit render times hack that fixes it (doesn't seem to be JUST dx11 then obviously), with it off, or with just the other one on it still glitches. I'm just going to leave them both on, as it seems to have no ill effects.
On my PC I need to have both new tweak options on or both off to get no glitches. If I have only the "run presentation in a separate thread" option on, then I get glitches. So let me ask you again: Please turn *BOTH* new tweak options off and test again. That's important for me because I actually want to delete the 2 new tweak options and treat them as always unchecked.

No, it does not. Might be time for a reboot and some more testing....
Yeah, maybe, cause it's really weird.

Yes. Movies are 23.976fps, 24fps and 29.970fps at a 60Hz display refresh and an Nvidia GTX260-216 on Vista x64. I just have to enable the "use D3D11 for presentation" switch, all other tweaks are always disabled, and the glitches are there. Without that option, no glitches at all. That´s perfectly reproducible every time. The 2 additional switches don´t solve that, unfortunately.
Funny. On my NVidia 9400 HTPC it's exactly the opposite. With 24fps @ 60Hz, I get glitches without D3D11 and no glitches with D3D11 on.