madVR - high quality video renderer (GPU assisted)

[GrandeBoma]

What error exactly?


"creating 3dlut file for pioneer tv display failed"

[SamuelMaki]

@ madshi: the lipsync bug was obviously not madvr related, it rather seems to be related to my monitor taking too long to change the display mode and JRiver by default not waiting long enough to start the audio (fixed with the "play silence" setting). In MPC the problem never happened.

So all is fine :)

I "fixed" that problem by disabling "automatic lipsync" at LAV-Audio...

[nevcairiel]

I "fixed" that problem by disabling "automatic lipsync" at LAV-Audio...

I should really rename that option or even remove it (make it be always on), it doesn't do what people think it does, and usually does only harm turning it off.

[Razoola]

For those of you who have problems with v0.80, with v0.79 working just fine for you, here are a couple of test builds:

http://madshi.net/madVR80tests.rar

Please let me know which of these test builds work fine for you and which don't. Basically there are 3 changes in v0.80 which could eventually cause the problem for you, so these test builds just test every possible combination of these 3 changes.

None of these 8 builds fix the issue for me. All of them either start with a really low presentation queue or the presentation queue quickly drops to zero. Composition rate message shows in OSD on all 8 builds on the sesondary display.

Going back to 079 the composition rate message does not show on the secondary display and the presentation queue does not drop to zero.

[madshi]

None of these 8 builds fix the issue for me. All of them either start with a really low presentation queue or the presentation queue quickly drops to zero. Composition rate message shows in OSD on all 8 builds on the sesondary display.

Going back to 079 the composition rate message does not show on the secondary display and the presentation queue does not drop to zero.
That's weird. Are you using a refresh rate changer (either madVR one or an external one)? If so, does it make a difference if you disable it?

[buyukbang]

Hi,

I'm using the latest intel hd 3000 drivers with its default settings. I've no other graphic related problem. I tested the test builts you provided today and also a few old builds like 0,70, 0.79 but all gave the same result. Here is the debug log :

http://netload.in/dateiGElqQbPe4V/madVR - log.txt.htm

Thanks...




Have you installed proper drivers for your GPU? Try the latest drivers from Intel's homepage. If that doesn't help you could create a debug log and upload it somewhere for me to look at.

[Razoola]

That's weird. Are you using a refresh rate changer (either madVR one or an external one)? If so, does it make a difference if you disable it?

I'm using madVRs refresh rate changer. You want me to disable it and run the 8 tests again?

[madshi]

Here is the debug log
Is there really a display attached? Or are you using some kind of remote control software to use your PC? Anyway, the log indicates that your GPU does not provide proper VSync scanline information to madVR. I don't know why. Either the drivers are broken, or not installed properly, or no display is attached, or you're using MS remote control.

I'm using madVRs refresh rate changer. You want me to disable it and run the 8 tests again?
Just the one with all "-".

[Razoola]

Just the one with all "-".

I just completed doing all 8. No change, same issues.

[aufkrawall]

Can you upload a small sample, please?

Here is one (23 MB):
http://www.mediafire.com/?s75ocev78dscmqh

Btw: I couldn't reproduce stuttering with RAW video (that's what I meant with high bitrates previously, sorry about that). :)

[kalston]

Oh, had missed that.
But did v0.79 behave differently?


I moved to JRiver MC recently (after madVR 0.80 was out) so I did a quick downgrade to verifiy and yes I also get the problem with madVR 0.79.

One thing I've not tried is to use JRiver MC's display mode switching instead of madVR's but I'm not sure it would make any difference.

In any case all is fine in MPC-HC and all is fine in JRiver MC IF I use the "play silence at startup for hardware synchronisation" OR switch the display mode beforehand (my desktop/gaming refresh rate differs from the one I use for video playback).

[Razoola]

Here is a log of what I'm seeing in 079 compared to 080. Please remember though that as I pointed out in the past the debug version of 080 does not suffer the same problem as 080 release version. Well it does suffer problems with the presentation queue but it recovers. In the release build it does not recover.

madVR079-080.zip (http://unibios.free.fr/madVR079-080.zip)

[buyukbang]

I'm using this mac mini dedicated to my TV as a HTPC just for multimedia. I collected this log while my TV is on, so display is attached for sure. But you're right about the remote control. I'm using Eventghost program to control players (pause/play/etc.) However this is neither a MS control nor a MS compatible one. IR receiver is integrated Apple one while the remote is a Logitech Harmony. Is there any known problem with remote softwares? If so, sorry I'm totally unaware of this problme? Any suggestion ?

Thanks...

Is there really a display attached? Or are you using some kind of remote control software to use your PC? Anyway, the log indicates that your GPU does not provide proper VSync scanline information to madVR. I don't know why. Either the drivers are broken, or not installed properly, or no display is attached, or you're using MS remote control.

[madshi]

Here is a log of what I'm seeing in 079 compared to 080. Please remember though that as I pointed out in the past the debug version of 080 does not suffer the same problem as 080 release version. Well it does suffer problems with the presentation queue but it recovers. In the release build it does not recover.
Hmmmmm... These logs show that your *render* queue is the problem, not the presentation queue. The presentation queue can only fill if the render queue is filled. If you have a problem you always need to find the "highest" queue in the OSD queue list which gets empty. In your case that's the render queue. So it seems that rendering isn't fast enough for whatever reason. BTW, which is your GPU queue size? 8? Even with v0.79 it seems that your render queue never gets higher than 6/8? Which OS, which GPU?

The logs show that presenting every other frame takes about 19ms. That's a full vsync duration. That also stops madVR from rendering quickly. Perhaps things would get better if you enabled the madVR option "run presentation in separate thread"? But it shouldn't really be necessary unless the GPU drivers stink. And that seems to be the case for you. I don't know why v0.79 works better for you, it could be a very small timing related difference. The key problem is that the rendering queue doesn't fill. And it doesn't fill because presenting frames (Direct3D API) often blocks the whole rendering for 19ms. Which it shouldn't.

I'm using Eventghost program to control players (pause/play/etc.) However this is neither a MS control nor a MS compatible one. IR receiver is integrated Apple one while the remote is a Logitech Harmony.
I don't mean that kind of remote software. I meant things like VNC, or PC Anywhere. It seems you're not using those. So I don't know why reading vsync scanline information fails on your PC. It's likely to be a GPU driver issue.

[THX-UltraII]

I should really rename that option or even remove it (make it be always on), it doesn't do what people think it does, and usually does only harm turning it off.

can you specify what it exactly does then nevcairiel?

[JustinChase]

Hmmmmm... These logs show that your *render* queue is the problem, not the presentation queue. The presentation queue can only fill if the render queue is filled. If you have a problem you always need to find the "highest" queue in the OSD queue list which gets empty. In your case that's the render queue. So it seems that rendering isn't fast enough for whatever reason.

Do you happen to be using the latest nVidia beta drivers?

I had to revert to version 290.36 for a very smilar issue. I went back several pages but didn't find the actual complaint, just that the queues weren't filling up. In my case it was the bottom 2 queues (presentation and render?) never filling up and video being a slideshow while audio was fine.

Sorry if this was already ruled out, or not the same issue, but it baffled me until I uninstalled, and resinstalled the older driver.

[Razoola]

Hmmmmm... These logs show that your *render* queue is the problem, not the presentation queue. The presentation queue can only fill if the render queue is filled. If you have a problem you always need to find the "highest" queue in the OSD queue list which gets empty. In your case that's the render queue. So it seems that rendering isn't fast enough for whatever reason. BTW, which is your GPU queue size? 8? Even with v0.79 it seems that your render queue never gets higher than 6/8? Which OS, which GPU?

The logs show that presenting every other frame takes about 19ms. That's a full vsync duration. That also stops madVR from rendering quickly. Perhaps things would get better if you enabled the madVR option "run presentation in separate thread"? But it shouldn't really be necessary unless the GPU drivers stink. And that seems to be the case for you. I don't know why v0.79 works better for you, it could be a very small timing related difference. The key problem is that the rendering queue doesn't fill. And it doesn't fill because presenting frames (Direct3D API) often blocks the whole rendering for 19ms. Which it shouldn't.

Yes I have the gpu queue size set to 8. The GPU in question is a 240GT with 290.53 drivers. OS is win7x64. I already tried the option 'run presentation in separate thread' but it did not help. Only thing that helps in 080 is going back to the old exclusive mode path

Do you see in the logs why one has the composition OSD message and the other does not?

[kerman]

Same movie frame rate, same display refresh rate? I'd suggest to try to find out why you got those 25 frame drops. First step would be to check whether the first movie always ends up with 0 frame drops while the other one always ends up with 25 frame drops. Or maybe it's random? In any case, check the madVR OSD to see which queues are getting empty when the frame drops occur and which queues stay full and report back here.

I found disabling DXVA2 (LAV 0.46) and I have no more dropped frames. With it checked, it depends on the specific movie; most of them got dropped frames (20-60), while (a very few) others no one frame dropped.

Tried to increase the presented frames in advance number to "8", and it did nothing; it gets empty and refills again constantly. If I increase to 16 I got LOTS of dropped frames. So for now I leave it by default at "4".

For the moment, the only thing I know is, NO DXVA2 = very few to none frames dropped.

My GPU is AMD HD6950 2GB, CPU Q6600@3.60GHz and 8GB RAM. OS Win7x64 and MPC-HC player.

[buyukbang]

Oh, OK I see now. No, I don't use any remote controlling softwares and this debug log generated while directly accessing to the PC.

But I'm sure that this is not related with wrong driver installation since I don't have any other problem with graphic card usage under my Windows 7 x64 at the moment:
- I can use LAV filter with Intel dxva / Intel quick synch
- I can play games without any issue.
- I tested other renderers: Halii, EVR Custom, etc... No problem like that.

Instead I'm highly suspecting about something else: Mac PC's use EFI instead of bios and in my case there is only Intel 3000 as the graphic card. I think this hardware requires a different software access, since, for example when I try to run Ubuntu Live, it does not even start and reports that it cannot detect the graphic card; similarly I cannot even install Ubuntu (not live), because it reports the same error. Ubuntu created Mac specific builds for that reason. Of course this is just a guess of mine.

@ALL,
is there any one having a Mac with Intel HD3000 as a single graphics card and Windows 7. Need to hear your experiences with Madvr, please...


@madshi,
Could you please be so kind to suggest me any other test cases like some other software, codec or anything else. May be I can collect any findings to help ou to understand the issue clearly. I want to use your MadVR on my Mac Mini as in my Laptop, Please :)

Thanks...


I don't mean that kind of remote software. I meant things like VNC, or PC Anywhere. It seems you're not using those. So I don't know why reading vsync scanline information fails on your PC. It's likely to be a GPU driver issue.


I'm using Eventghost program to control players (pause/play/etc.) However this is neither a MS control nor a MS compatible one. IR receiver is integrated Apple one while the remote is a Logitech Harmony.

[madshi]

Yes I have the gpu queue size set to 8. The GPU in question is a 240GT with 290.53 drivers. OS is win7x64. I already tried the option 'run presentation in separate thread' but it did not help. Only thing that helps in 080 is going back to the old exclusive mode path

Do you see in the logs why one has the composition OSD message and the other does not?
No, that composition message is still a mystery to me. Here are 4 new test builds:

http://madshi.net/madVR7980mix.rar

These are a blend of v0.79 and v0.80. They're numbered 1-4. Number 1 is nearest to v0.79, number 4 is nearest to v0.80. Please try number 1 first. I hope number 1 will work. Test number 1 first, then 2 etc. You can stop testing when the problem starts appearing. I need to know which of those 4 starts breaking things for you.

I found disabling DXVA2 (LAV 0.46) and I have no more dropped frames. With it checked, it depends on the specific movie; most of them got dropped frames (20-60), while (a very few) others no one frame dropped.
Ah, ok, makes sense. DXVA2 can be troublesome, especially with ATI cards.

But I'm sure that this is not related with wrong driver installation since I don't have any other problem with graphic card usage under my Windows 7 x64 at the moment:
- I can use LAV filter with Intel dxva / Intel quick synch
- I can play games without any issue.
- I tested other renderers: Halii, EVR Custom, etc... No problem like that.
I'm not sure if any of these need VSync scanline information. madVR does, and your GPU driver doesn't seem to supply this information. So I believe it's probably a driver (installation) issue of some sort.

Instead I'm highly suspecting about something else: Mac PC's use EFI instead of bios and in my case there is only Intel 3000 as the graphic card. I think this hardware requires a different software access, since, for example when I try to run Ubuntu Live, it does not even start and reports that it cannot detect the graphic card; similarly I cannot even install Ubuntu (not live), because it reports the same error. Ubuntu created Mac specific builds for that reason.
I don't think the different bios is the cause of the problem.

@madshi,
Could you please be so kind to suggest me any other test cases like some other software, codec or anything else. May be I can collect any findings to help ou to understand the issue clearly. I want to use your MadVR on my Mac Mini as in my Laptop, Please :)
There isn't really anything I can do. madVR needs vsync scanline information and your GPU/driver doesn't deliver it. The only thing I can suggest is try different driver versions. I've been told there are 2 different types of Intel GPU drivers. Maybe you can try both, maybe one of them will work. I don't know the details, though. Maybe someone else can help out here?

[madshi]

"creating 3dlut file for pioneer tv display failed"
Argh, that's too bad. Ok, let me see. Currently madVR uses the following script to create 3dluts:

Input_Primaries %yourMeasuredPrimaries% (but white point always D65 = 0.31272661468101209 0.32902313032606195)
Output_Primaries %yourMeasuredPrimaries% (with measured white point)
Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0
Input_Range 16 235
Output_Range 16 235
Input_Bit_Depth 8
Output_Bit_Depth 16
Gamut_Measurements %yourMeasuredGamut%

[kerman]

I've been reading some previous discussion about color range, and I've it still not clear about correct setup, given so many elements. I actually have it this way:

Catalyst CC: RGB 4:4:4 Pixel Format PC Standard (Full RGB)
LAV Video RGP output levels: Untouched (as input)
madVR device properties: PC levels (0-255)
Plasma display: Black set to "High" (Full 0-255)

Is this setup correct? my common sense tells me all things have to be setted up with the same values, but not 100% sure.

[703]

A.I. affects texture filtering quality.

http://www.3dcenter.org/artikel/amd-mit-neuen-schwaechen-bei-der-filterqualitaet

So???:o

So does the AMD control panel settings such as AA, AF and AI affects how MadVR renders? Have you tested this?

[madshi]

Is this setup correct? my common sense tells me all things have to be setted up with the same values, but not 100% sure.
Looks alright to me. But you should always check black & white levels ("brightness" and "contrast" controls in your plasma) with a calibration DVD/Blu-Ray. A bit of brightness/contrast tuning might be necessary to have it setup perfectly. In a grayscale you should be able to see the bars from ~ 15 - 235. All levels under 15 should be invisible (identical to deepest black). All levels above 235 should be invisible (identical to brightest white). There's some debate about whether showing some more bars above 235 might make sense. Personally, I don't think so, but then I'm mostly watching Blu-Rays, which are usually limited to 235.

[Qaq]

Catalyst CC: RGB 4:4:4 Pixel Format PC Standard (Full RGB)OKLAV Video RGP output levels: Untouched (as input)OK. Isn't it for RGB output only BTW?madVR device properties: PC levels (0-255)OKPlasma display: Black set to "High" (Full 0-255)Its only brightness range and what about color space? In some TVs you have to set HDMI input setting to 'PC' to get RGB.

[Razoola]

No, that composition message is still a mystery to me. Here are 4 new test builds:

http://madshi.net/madVR7980mix.rar

These are a blend of v0.79 and v0.80. They're numbered 1-4. Number 1 is nearest to v0.79, number 4 is nearest to v0.80. Please try number 1 first. I hope number 1 will work. Test number 1 first, then 2 etc. You can stop testing when the problem starts appearing. I need to know which of those 4 starts breaking things for you.

Some progress. Test 1 and test 2 are fine, the composition message is also gone from the OSD. Test 3 is where I see the queue problem appear, the composition message also appears in this build.

Many thanks for taking the time to look into this.

[Trib]

Want to say thanks to Madshi and anyone who has helped him to make this superb renderer. So much better than any other imo! =)

[GrandeBoma]

Argh, that's too bad. Ok, let me see. Currently madVR uses the following script to create 3dluts:


that worked. however, i must say that inserting the measured values does not really bring gamut to reference, in my case for red it was required some manual trial and error tinkering of settings to achieve the perfect measurement. Green and blue on the other hand were perfect

[Peekstra]

When using madVR to display a movie on a secondary monitor using the Windows desktop on the primary screen becomes (almost) impossible. For example: some windows appear semi transparent and can't be clicked on with the mouse. This makes the computer unusable for other things when someone else is watching a movie.

Will a future version of madVR resolve this or is this a limitation of the hardware, OS or drivers (Win7X64, AMD 6950, ZP811)?

[madshi]

Some progress. Test 1 and test 2 are fine, the composition message is also gone from the OSD. Test 3 is where I see the queue problem appear, the composition message also appears in this build.
Ok, how about these 2 test builds?

http://madshi.net/madVRazoola.rar

Want to say thanks to Madshi and anyone who has helped him to make this superb renderer. So much better than any other imo! =)
:)

that worked. however, i must say that inserting the measured values does not really bring gamut to reference, in my case for red it was required some manual trial and error tinkering of settings to achieve the perfect measurement. Green and blue on the other hand were perfect
Not sure why. This would be a topic for yesgrey (the yCMS author). Unfortunately he's still not back to "active duty". He's taking a break for personal reasons. He's planning to get back to yCMS sooner or later, though.

When using madVR to display a movie on a secondary monitor using the Windows desktop on the primary screen becomes (almost) impossible. For example: some windows appear semi transparent and can't be clicked on with the mouse. This makes the computer unusable for other things when someone else is watching a movie.

Will a future version of madVR resolve this or is this a limitation of the hardware, OS or drivers (Win7X64, AMD 6950, ZP811)?
I think some people have this problem sometimes, but not all. You could try disabling aero / desktop composition to see if that makes a difference. You could also try modifying the way your monitors are set up. E.g. move the secondary monitor to the left side of the primary monitor instead of the right side, or something like that. Maybe some fiddling around like that helps?

[Razoola]

Ok, how about these 2 test builds?

http://madshi.net/madVRazoola.rar


madVR, 79InitPresParams.ax = Good queues + no composition message..
madVR, moved aero switch.ax = Bad queues + composition message.

[madshi]

madVR, 79InitPresParams.ax = Good queues + no composition message..
madVR, moved aero switch.ax = Bad queues + composition message.
Ok, now I know which exact function causes the problem. Now let's check which part of the function is responsible:

http://madshi.net/madVRazo2.rar

[THX-UltraII]

quick question:

Does madVR offer better picture quality than EVR Custom if I only watch 1080p material on a 1080p display device? I use LAV decoder for my NVIDIA GTX 460 to do hardware decoding.

[RBG]

quick question:

Does madVR offer better picture quality than EVR Custom if I only watch 1080p material on a 1080p display device?

Yes it does. Mostly because all of video material is 4:2:0, which means that you've got only a half of chroma resolution in both dimensions. To be more precise on typical 1920x1080 video chroma resolution will be 960x540, and it has to be properly upsampled.

[kerman]

Looks alright to me. But you should always check black & white levels ("brightness" and "contrast" controls in your plasma) with a calibration DVD/Blu-Ray. A bit of brightness/contrast tuning might be necessary to have it setup perfectly. In a grayscale you should be able to see the bars from ~ 15 - 235. All levels under 15 should be invisible (identical to deepest black). All levels above 235 should be invisible (identical to brightest white). There's some debate about whether showing some more bars above 235 might make sense. Personally, I don't think so, but then I'm mostly watching Blu-Rays, which are usually limited to 235.

Thanks for help guys. Im afraid Ill have to get any affordable device to calibrate my tv for color accuracy. Not cheap though..

BTW, do youy guys have "gamma processing" enabled on madVR. It comes unchecked by default, but wondering if it may improve the final image quality. Im just looking for the picture the most accurate to the source.

[dukey]

Yes it does. Mostly because all of video material is 4:2:0, which means that you've got only a half of chroma resolution in both dimensions. To be more precise on typical 1920x1080 video chroma resolution will be 960x540, and it has to be properly upsampled.

Well since 1 chroma pixel would exactly cover 4 luminance ones, I can't exactly see how any renderer would mess that up.

[madshi]

See first page of this thread (red fonts on black background).

[Razoola]

Ok, now I know which exact function causes the problem. Now let's check which part of the function is responsible:

http://madshi.net/madVRazo2.rar

Problem in 'store window size' build only, other two are fine.

[dukey]

See first page of this thread (red fonts on black background).

Yeah but he is using the native resolution. Even a nearest resize would produce the correct upsampling.

[6233638]

So I realise this may not have been the intention of these test builds, but I just reset all my madVR settings to the defaults, let a two minute clip run and made a note of the dropped frames & presentation glitches.

In these cases, the dropped frames seemed to only appear at the start of the clip, and it never dropped any past the first couple of seconds. The numbers are averaged from running the tests twice.

0.80 release: 7 / 69
1 - tools, settings, dither, aero: 22 / 69
2 - osd, uploading, vsync, rendering: 22 / 65
3 - direct3d: 7 / 78
4 - framequeue: 7 / 57
79InitPresParams: 22 / 65
moved aero switch: 7 / 68
double code: 22 / 63
order changed: 22 / 61
store window size: 7 / 69Does that tell you anything useful?

Yeah but he is using the native resolution. Even a nearest resize would produce the correct upsampling.That's not correct at all. Chroma looks terrible if you use nearest neighbour resampling.

There are noticeable differences between all the various chroma options in madVR, and after doing further testing, which I had planned on doing a big write-up post on, I now use Mitchell-Netravali for chroma upsampling, previously Bicubic 75. (I was able to find some test cases where bicubic exhibited ringing, and have yet to find anything where aliasing has been an issue with MN for chroma)

[nevcairiel]

Yeah but he is using the native resolution. Even a nearest resize would produce the correct upsampling.

No, it would not.
When you reduce the resolution to one quarter of the original, information is lost (4:2:0 is one quarter chroma resolution).
You need a proper reconstruction of that data, and nearest neighbor resize will just produce 4 pixels of the same color, which is not how the original looked like (probably not even close)

[madshi]

Problem in 'store window size' build only, other two are fine.
Ok. Can you please check this build to confirm that the problem is gone for you:

http://madshi.net/madVRmaybeFixed.rar

So I realise this may not have been the intention of these test builds, but I just reset all my madVR settings to the defaults, let a two minute clip run and made a note of the dropped frames & presentation glitches.

In these cases, the dropped frames seemed to only appear at the start of the clip, and it never dropped any past the first couple of seconds. The numbers are averaged from running the tests twice.

1 - tools, settings, dither, aero: 22 / 69
2 - osd, uploading, vsync, rendering: 22 / 65
3 - direct3d: 7 / 78
4 - framequeue: 7 / 57
79InitPresParams: 22 / 65
moved aero switch: 7 / 68
double code: 22 / 63
order changed: 22 / 61
store window size: 7 / 69Does that tell you anything useful?
It seems you either get 7 or 22 frame drops in all the tests. I'm wondering whether it's random which results you get, or whether it's really caused by the differences in the test builds. FWIW, e.g. the "79InitPresParams" and "store window size" madVR builds are almost identical. The differences between all the other builds are much bigger. So I tend to think that the results are more random than useful. Razoola's test results seem to be reliable because he saw the composition rate in some of those builds in the madVR OSD, while he didn't see it in other builds. Furthermore all of this results were conclusive. If his test results had been random, I would have run into some sort of contradiction sooner or later.

[Razoola]

Ok. Can you please check this build to confirm that the problem is gone for you:

http://madshi.net/madVRmaybeFixed.rar


Yes my issue is fixed in this build. Many thanks for spending the time looking into this.

[madshi]

Good to hear. To be honest, I don't really understand why the "fix" I implemented now changes anything. It's basically the same as v0.80, just some code sections re-ordered. Makes no sense to me. But well, as long as it works...

[Razoola]

Good to hear. To be honest, I don't really understand why the "fix" I implemented now changes anything. It's basically the same as v0.80, just some code sections re-ordered. Makes no sense to me. But well, as long as it works...

Maybe it had something to do with the fact I have multi gpus in my system, but like you say now that its working :)

[Damien147]

So does the AMD control panel settings such as AA, AF and AI affects how MadVR renders? Have you tested this?

I haven't cause in general I prefer default 3d settings in ccc and tweaking in game but I've read previous posts mentioning that AA,AF affects PQ(not about A.I.).
About A.I. from a quick test I just did I can't see a difference.So madshi is probably right.
In the past I thought it caused slight shimmering but it was placebo probably.

[madshi]

I believe I have found a bug.
Switching to the "old path" exclusive mode(as in, not only disabling present several frames in advance, but actually setting the media player to full screen mode) limits the number of backbuffers to 3, in both windowed and exclusive mode.
Turns out there isn't anything I can do about this. Vista introduced a new "Direct3D9Ex" interface, which I have to use to get more than 3 backbuffers. However, the "old path" exclusive mode does not work with "Direct3D9Ex", it only works with the older "Direct3D9", and that does not support more than 3 backbuffers. So there isn't really anything I can do. If you want to use the old exclusive mode path, you're automatically stuck with 3 backbuffers in both windowed and exclusive mode.

[madshi]

Cosmetic bug:
If the ffmpeg decoders aren't present, madVR options will still default to enabling the H.264 and MPEG2 decoder. It should ideally uncheck and grey out those options.
Done.

Suggestion:
If the ffmpeg decoders aren't present during filter registration, then don't include the H264/MPEG2/VC-1 mediatypes.
Tried, but failed. The MSVC++ base classes have some linker magic which require the mediatypes to have a specific name. So basically I can only use one exact list of mediatypes. At least I don't see how I could do this differently in any easy way. And I don't think this is important enough to warrant hours of searching.

[6233638]

It seems you either get 7 or 22 frame drops in all the tests. I'm wondering whether it's random which results you get, or whether it's really caused by the differences in the test builds. FWIW, e.g. the "79InitPresParams" and "store window size" madVR builds are almost identical. The differences between all the other builds are much bigger. So I tend to think that the results are more random than useful.The dropped frame numbers I get were consistent and repeatable, presentation glitches varied somewhat, maybe +/-5 over the whole set of testing I did. (that's why I tried each at least twice, and averaged) Going back to those two builds now, I still get the same difference in dropped frames.

The new build posted averages 22/53. As I said, the dropped frames only seem to be initial numbers within the first few seconds of playback, but it seemed strange, so I thought I should mention it. (presentation glitches keep increasing with the default flush settings)

Whatever that small difference is, must be doing something.



Using the "framequeue" build which showed the least number of dropped frames & presentation glitches, and changing the flushing to don't/don't/don't/sleep, I was able to watch a 40 minute 30p@60Hz video without any framedrops/presentation glitches past the first minute, where it climbed to 7/43 and then stayed there to the end.

I need to do extended testing with this using some longer videos (sometimes problems only show up after an hour or so) and with the "maybe fixed" build, but it may be a solution for people that need to run the latest Nvidia drivers. (0.80 seemed fine with these flush settings until I tried longer videos though)

[madshi]

What happens if you enable the option "delay playback until render queue is full"? Shouldn't that take care of those framedrops at the start of playback?