madVR - high quality video renderer (GPU assisted)

[baii]

Having problem with render queue not filling(stuck at 1-2 and frame drops) after pasue(s),where using stop and play again will fix the issue. This is on amd and windows 10. Any way I can track the issue with log or w.e? The are no crash etc.

Sent from my SM-T700 using Tapatalk

[clsid]

This should help solve the batch script problems:
https://sites.google.com/site/eneerge/scripts/batchgotadmin

[XRyche]

That is very weird because the original log you uploaded clearly shows that there's a 14 second delay caused by compiling the OpenCL kernel. The compiling of the OpenCL kernel should not be done if you use other chroma upscaling and image doubling algorithms.


It gets weirder and weirder. OpenCL compiling is done at startup, not when entering FSE mode. So OpenCL compiling doesn't explain delays when entering FSE mode.

Unfortunately the new log isn't helpful (thanks for compressing it though). The log still seems to be from the old build. I think what happened is that you probably copied the new build into the madVR folder, and then did the manual file rename thing afterwards. By doing that you practically disabled the new build again, because you renamed it to "madVR [release].ax" and the media player only ever uses "madVR.ax". Please copy the special XRyche build into the madVR folder and afterwards do *not* rename the files. The new build is a debug build. Maybe I should have named it "madVR [debug].ax" to avoid confusion, but I did say that it was a debug build.

I will need 3 logs from you now. Sorry about the extra work, but your problem descriptions are very confusing to me (see above). So I need those 3 logs to understand what's really going on:

1) Same as before. Just start playback with NNEDI3 enabled. Wait for the video to appear. Then stop.
2) Start in windowed mode, so the delay does *not* occur, let it play for about 10 seconds. Then switch to FSE mode, so the delay occurs. Wait for the video to appear. Then stop.
3) Disable NNEDI3 everywhere (all chroma upscaling, luma doubling, chroma doubling, luma quadrupling and chroma quadrupling). Start playback, reproduce the long delay, wait for the video to appear. Then stop.

Please create 3 separate logs for these 3 situations. After every situation simply rename the log file with a suitable name to explain what the log contains. Thanks!




Actually, I forgot to rename the files back to their original names after the last debug.......oops again. Maybe I should make the word "oops" part of my signature.

Anyway, here are the three separate debug logs: http://www.mediafire.com/download/8o5w89m84kdc5oo/madVR_NNEDI3_FSE-_log.zip ,http://www.mediafire.com/download/w2rj29jv8ewdvty/madVR_NNEDI3_Windowed%2CFSE-_log.zip ,http://www.mediafire.com/download/uj4fe3162pqkp7j/madVR_Super_xbr_FSE-_log.zip . Just to reiterate, the long delay only happens with image doubling and that's why I used Super-xbr in one of the debug sessions.

[dansrfe]

I was referring to the 'apply SuperRes first' checkbox in the upscaling refinement section.

[ShadyCrab]

Okay, using the newest MPC-HC + LAV Filters (internal) which both now support HEVC 10 bit DXVA2 Native decoding, I am having issues using Native with madVR. My GPU is a GTX 960 which supports 10 bit HEVC decoding in full, driver is 355.98 on Win 10,.

Though, in general, I noticed a lot of instability with DXVA2 Native in madVR (no issues with copy-back).
1. If I enable 'use a separate device for DXVA decoding' for 8-bit content, I get a black screen but audio. If I skip forward slightly relatively fast to see the following warning, I see that madVR reports 'creating dxva decoding surface fails'. If I disable this option, 8-bit content works correctly with no black screen or crashing.
2. In general, in 10-bit, I get the same black screen, but if you skip forward, I just get green screen. I think this might be because madVR doesn't accept 10 bit DXVA input, I don't know.

My last question with regards to native is about Chroma upscaling. I see the two options to use DXVA2 Chroma upscaling when native decoding is enabled, but I was wondering about the behaviour when you disable them. I remember in older builds, you would get a slight blur to the Chroma when using a NVidia card because they didn't support a certain texture format or something. Is this still the same behaviour when you disable those options to use madVR chroma upscaling?

Want to report that updating my graphics driver fixed NNEDI3 upscaling. It might be a good idea to regenerate whatever data NNEDI3 uses when updating to the D3D11 interop build for the first time, might help fix many peoples issues in regards to NNEDI3 (or in general, when using a newer build, regenerate the data). Or put a warning on the front page, saying if NNEDI3 isn't working, reinstall/update your video driver.

[huhn]

you should avoid DXVA native with nvidia it degrades picture quality with madVR.

[Asmodian]

I was referring to the 'apply SuperRes first' checkbox in the upscaling refinement section.

That means before the other options in upscaling refinement not before upscaling. :)

[dansrfe]

I'm watching Interstellar and when going from 2.41 => 16:9 it flickers for a fraction of a second when it disables the crop. Is it plausible to disable the crop one second prior to rendering a larger frame?

On a separate note, black bar detection isn't quite working as expected between timecode 01:29:07 - 01:29:18 of Interstellar, instead it goes back and forth between 2.41 and 16:9. You must start play back 5-10 seconds prior to 01:29:07 for the problem to appear.

Let me know if you require a cut. Settings: detect hard coded black bars, crop black bars, rest disabled.

[RyuzakiL]

Does the said combination works?

I mean the last time I upgraded to Windows 10, it destroyed my MadVr setup. Lots of glitches especially when using FSE10bit+DX11.

I am currently on Windows 8 and my current MadVR setup works smooth and silky using Xtreme-G's Tweaked AMD Catalyst Driver. But seeing that there's a new version of MadVR, I wonder if it's safe to use it on Windows 10?

[QBhd]

Does the said combination works?

I mean the last time I upgraded to Windows 10, it destroyed my MadVr setup. Lots of glitches especially when using FSE10bit+DX11.

I am currently on Windows 8 and my current MadVR setup works smooth and silky using Xtreme-G's Tweaked AMD Catalyst Driver. But seeing that there's a new version of MadVR, I wonder if it's safe to use it on Windows 10?

I just tried that Xtreme-G driver (on a Windows 8.1 x64 platform)... I would recommend NOT to use it. Black levels are not correct and the colors are a bit off. Whatever tweaks are being used in that driver do absolutely nothing for madVR performance, and actually hurt picture quality.

QB

[Siso]

Madshi,
is it possible to add an option like the one "zoom small black bars away"(which works very good on 21:9 displays for 2.35:1, 2.39:1, 2.40:1 ratios),a new option which crops the picture, in other words some sort of smart crop feature? :)

[madshi]

Having problem with render queue not filling(stuck at 1-2 and frame drops) after pasue(s),where using stop and play again will fix the issue. This is on amd and windows 10. Any way I can track the issue with log or w.e? The are no crash etc.
Things like this can very hard to debug. Have you tried toggling/modifying all those countless rendering options in madVR? My first suggestion would be to restore the standard settings. If that doesn't help, try increasing or decreasing the queue size or the number of prepresented frames. Does this only occur in fullscreen exclusive mode or also in windowed mode? Primary or secondary display?

This should help solve the batch script problems:
https://sites.google.com/site/eneerge/scripts/batchgotadmin
Thanks. When researching all this I've seen this solution, too, but creating a temp vbs script file sounded quite scary to me. Isn't scripting also disabled on some (many?) PCs for security reasons?

Actually, I forgot to rename the files back to their original names after the last debug.......oops again. Maybe I should make the word "oops" part of my signature.

Anyway, here are the three separate debug logs: http://www.mediafire.com/download/8o5w89m84kdc5oo/madVR_NNEDI3_FSE-_log.zip ,http://www.mediafire.com/download/w2rj29jv8ewdvty/madVR_NNEDI3_Windowed%2CFSE-_log.zip ,http://www.mediafire.com/download/uj4fe3162pqkp7j/madVR_Super_xbr_FSE-_log.zip . Just to reiterate, the long delay only happens with image doubling and that's why I used Super-xbr in one of the debug sessions.
Thanks. The good news is that all those logs have the same problem: It's still the NNEDI3 kernel compilation. It seems that I'm compiling the kernel even if you use super-xbr or NEDI instead of NNEDI3. I'll fix that for the next build, so then you should hopefully be able to use super-xbr or NEDI without delay. But I would still like to find out why the NNEDI3 kernel is recompiled on your PC every single time. That's not right, either.

The bad news is that the logs are still created by the old build, not the special build I made for you. To be honest, I'm not sure if it's my fault or yours. Maybe I just sent you the wrong build or something. Can we make one last try:

1) Install standard v0.89.3.
2) Extract the XRyche special build I uploaded and linked to earlier.
3) Simply copy the special build into the madVR folder and overwrite the old file.
4) Create the log.

No file renamings at any time. No batch files. Nothing. After you're done, reinstall standard v0.89.3.

I was referring to the 'apply SuperRes first' checkbox in the upscaling refinement section.
Please always quote me (the part that replies to you), otherwise I have to manually search through the thread to find the related posts. Thanks.

What is the quality difference between applying SuperRes before/after image upscaling? Is this difference only visible when upscaling 2x or more?
The "apply SuperRes first" option defines whether madVR first applies SuperRes and afterwards e.g. AdaptiveSharpen, or the other way round. According to my own tests it probably makes more sense to apply SuperRes first because the other way round means that SuperRes often undoes what AdaptiveSharpen did. But in the end, it's your choice.

I'm watching Interstellar and when going from 2.41 => 16:9 it flickers for a fraction of a second when it disables the crop. Is it plausible to disable the crop one second prior to rendering a larger frame?
I'm seeing zero flickering here. Are we talking about windowed or fullscreen playback? Can you describe how the flickering looks like exactly? Maybe can could even capture it with a screen recoding software somehow?

On a separate note, black bar detection isn't quite working as expected between timecode 01:29:07 - 01:29:18 of Interstellar, instead it goes back and forth between 2.41 and 16:9. You must start play back 5-10 seconds prior to 01:29:07 for the problem to appear.
I do have Interstellar here, but I can't reproduce any problems around 01:29:07 - 01:29:18. Maybe we have a different country edition with slightly different time codes? At 01:29:07 etc there's no switch between 2.41 and 16:9 at all, it's all straight 2.41 here.

Let me know if you require a cut. Settings: detect hard coded black bars, crop black bars, rest disabled.
Would be great if you could create a cut which allows me to easily reproduce the problem you're seeing.

is it possible to add an option like the one "zoom small black bars away"(which works very good on 21:9 displays for 2.35:1, 2.39:1, 2.40:1 ratios),a new option which crops the picture, in other words some sort of smart crop feature? :)
Activating both "zoom small black bars away" + "crop black bars" should already do that, I think.

Okay, using the newest MPC-HC + LAV Filters (internal) which both now support HEVC 10 bit DXVA2 Native decoding, I am having issues using Native with madVR. My GPU is a GTX 960 which supports 10 bit HEVC decoding in full, driver is 355.98 on Win 10,.

Though, in general, I noticed a lot of instability with DXVA2 Native in madVR (no issues with copy-back).
1. If I enable 'use a separate device for DXVA decoding' for 8-bit content, I get a black screen but audio. If I skip forward slightly relatively fast to see the following warning, I see that madVR reports 'creating dxva decoding surface fails'. If I disable this option, 8-bit content works correctly with no black screen or crashing.
Seems to work fine here. Does that happen with all videos or just with some? Is that with DXVA deinterlacing active or inactive?

2. In general, in 10-bit, I get the same black screen, but if you skip forward, I just get green screen. I think this might be because madVR doesn't accept 10 bit DXVA input, I don't know.
I'm not sure how LAV handles that, but I suppose LAV should detect that madVR doesn't accept 10bit DXVA input and switch DXVA native off? I don't know, I can't test it because I don't have a GPU capable of decoding 10bit via DXVA at the moment. Or are you using a different decoder than LAV?

My last question with regards to native is about Chroma upscaling. I see the two options to use DXVA2 Chroma upscaling when native decoding is enabled, but I was wondering about the behaviour when you disable them. I remember in older builds, you would get a slight blur to the Chroma when using a NVidia card because they didn't support a certain texture format or something. Is this still the same behaviour when you disable those options to use madVR chroma upscaling?
you should avoid DXVA native with nvidia it degrades picture quality with madVR.
^

Native DXVA is only for people who want low power consumption or who have slow PCs. If you can, use DXVA copyback or software decoding instead.

Want to report that updating my graphics driver fixed NNEDI3 upscaling. It might be a good idea to regenerate whatever data NNEDI3 uses when updating to the D3D11 interop build for the first time, might help fix many peoples issues in regards to NNEDI3 (or in general, when using a newer build, regenerate the data). Or put a warning on the front page, saying if NNEDI3 isn't working, reinstall/update your video driver.
Regenerating the compiled kernel shouldn't be necessary or even useful because the compiled kernel is a totally separate thing from the interop. Whether I do interop or not and in which form is totally unknown to OpenCL at the moment when I run the kernel.

[nevcairiel]

I'm not sure how LAV handles that, but I suppose LAV should detect that madVR doesn't accept 10bit DXVA input and switch DXVA native off? I don't know, I can't test it because I don't have a GPU capable of decoding 10bit via DXVA at the moment. Or are you using a different decoder than LAV?

When LAV connects using P010 and then asks the renderer to switch into DXVA-Surface mode, and the renderer doesn't complain - then how would LAV tell that the renderer doesn't actually support P010-DXVA? :)

[madshi]

When LAV connects using P010 and then asks the renderer to switch into DXVA-Surface mode, and the renderer doesn't complain - then how would LAV tell that the renderer doesn't actually support P010-DXVA? :)
I don't know. You didn't tell me yet that there was a problem with this... :p So what would be the best moment to reject DXVA mode? E.g. when you call SetSurfaceType, I can't check the format yet, I think? When is the best time and the best way to check the format? To be honest, it's been ages since I looked into my native DXVA2 code, so I'm kinda out of touch on the implementation details... :scared:

[ryrynz]

I'm not sure what the two of you mean. Can you clarify?


If I update the window behaviour it doesn't show instantly, only when I change the window size.


Have you tried installing a different GPU driver version?


Reverted and it was okay. Did a fresh upgrade over it and that's fixed it.

[madshi]

If I update the window behaviour it doesn't show instantly, only when I change the window size.
What does "window behaviour" mean? Do you mean zoom modes like "touch window from inside" etc? The media players currently do not inform madVR about these modes. madVR just *guesses* the mode based on which target rect the media player sends to madVR. Now imagine you play e.g. a 720p file and MPC-HC displays it as 1280x720 pixels. madVR cannot know whether this is 100% view, touch window from inside, touch window from outside or stretch to window. All of those are possible. Only when you scale, madVR can find out which mode is really active. In a future build I'll add an interface for the media players to tell madVR which zoom mode they're in, so that madVR doesn't have to guess.

[nevcairiel]

I don't know. You didn't tell me yet that there was a problem with this... :p So what would be the best moment to reject DXVA mode? E.g. when you call SetSurfaceType, I can't check the format yet, I think? When is the best time and the best way to check the format? To be honest, it's been ages since I looked into my native DXVA2 code, so I'm kinda out of touch on the implementation details... :scared:

Actually, I mentioned it in a PM in August (around the 11th, i think?). :p

Best would be of course if you just add P010 support, check the surface type and handle it accordingly.

Otherwise failing in GetAvailableSurfaceTypeByIndex/SetSurfaceType would be best. The Media Type is present at that time, since this is called in CompleteConnect.

[madshi]

Actually, I mentioned it in a PM in August (around the 11th, i think?). :p

Best would be of course if you just add P010 support, check the surface type and handle it accordingly.

Otherwise failing in GetAvailableSurfaceTypeByIndex/SetSurfaceType would be best. The Media Type is present at that time, since this is called in CompleteConnect.
Thanks. Must have missed it or forgot about it, sorry. Will add it to the next (official) build.

[clsid]

Thanks. When researching all this I've seen this solution, too, but creating a temp vbs script file sounded quite scary to me. Isn't scripting also disabled on some (many?) PCs for security reasons?The most important part is the admin check.
The vbs should work on most systems, even with AV installed. You could check for failure and prompt user to run as admin. Or just leave it out and always prompt.

[abotiz]

Hi
If i only watch 1080 or remux from my htpc to a projector with both are connected to a AV receiver, does it matter if i use MPC-HC with madvr or Total media theater?
could i get a better picture if i use this filter Or does the AV receiver handle all the signals and it doesn't matter what filter or player i use?
i Am after for the best sound and picture.
thnx

[huhn]

Hi
If i only watch 1080 or remux from my htpc to a projector with both are connected to a AV receiver, does it matter if i use MPC-HC with madvr or Total media theater?
could i get a better picture if i use this filter Or does the AV receiver handle all the signals and it doesn't matter what filter or player i use?
i Am after for the best sound and picture.
thnx

than you need it. it about complicated YCbCr conversation and high bit deep processing. you can read about it here: http://forum.doom9.org/showthread.php?p=1271416#post1271416

[madshi]

That's too bad. I thought it could go into "trade quality for performance" subcategory just fine
I'll try to make this work by getting MPC-HC/-BE devs to notify me when subtitles are enabled/disabled.

I think Lav Video Decoder renders the subtitles, you'll have to ask nevcairiel for more information.
nevcairiel has agreed (thanks!) to give madVR some control over DVD subtitles. So this problem should hopefully be solved in a future build. Not this weekend yet, though.

The most important part is the admin check.
The vbs should work on most systems, even with AV installed. You could check for failure and prompt user to run as admin. Or just leave it out and always prompt.
I'll add it to my to do list to find a better solution for debug/release switching. Not sure exactly which solution I'll end up with, though. And it may take a while until I get to that. Thanks for your suggestions, in any case.

[XRyche]

Thanks. The good news is that all those logs have the same problem: It's still the NNEDI3 kernel compilation. It seems that I'm compiling the kernel even if you use super-xbr or NEDI instead of NNEDI3. I'll fix that for the next build, so then you should hopefully be able to use super-xbr or NEDI without delay. But I would still like to find out why the NNEDI3 kernel is recompiled on your PC every single time. That's not right, either.

Maybe the fact that NNEDI3 isn't visual working right either might be a clue.

Having Super-xbr work without the delay would be much appreciated in itself. I prefer NNEDI3 but Super-xbr is pretty close.



The bad news is that the logs are still created by the old build, not the special build I made for you. To be honest, I'm not sure if it's my fault or yours. Maybe I just sent you the wrong build or something. Can we make one last try:

1) Install standard v0.89.3.
2) Extract the XRyche special build I uploaded and linked to earlier.
3) Simply copy the special build into the madVR folder and overwrite the old file.
4) Create the log.

No file renamings at any time. No batch files. Nothing. After you're done, reinstall standard v0.89.3.




This is what I did last time. It even says in the madVR cpl that it is v0.89.3. I honestly didn't pay attention what the version number was when I used the madvr.ax file from madVRXRyche1.

Actually, I did use the "activate debug mode.bat" could that be the reason why it's showing it's an old build?

If not I'll re-download v.0.89.3 and madVRXRyche1 and use those. If it was because I was using the .bat file I'll just make 3 new logs without using the batch file and replacing madvr.ax with the file in madVRXRyche1. Either way it will be 5 or 6 hours before I can actually do it. Sorry for the delay.

[madshi]

The bad news is that the logs are still created by the old build, not the special build I made for you. To be honest, I'm not sure if it's my fault or yours. Maybe I just sent you the wrong build or something. Can we make one last try:

1) Install standard v0.89.3.
2) Extract the XRyche special build I uploaded and linked to earlier.
3) Simply copy the special build into the madVR folder and overwrite the old file.
4) Create the log.

No file renamings at any time. No batch files. Nothing. After you're done, reinstall standard v0.89.3.
This is what I did last time.

[...]

Actually, I did use the "activate debug mode.bat".
See the bold part in my quote. Just follow my instructions to the letter and it should work this time. The delay is not a problem. And one log should be good enough. Thanks.

[dansrfe]

Would be great if you could create a cut which allows me to easily reproduce the problem you're seeing.

https://www.dropbox.com/s/s4f3i4dlvkzet7r/cut.mkv?dl=1

So, this cut show's 2.39 <=> 1.78 crop loop problem.

I can't reliably reproduce the initial transition partial flicker problem; if I can in another source then I'll post a cut of that.

[madshi]

https://www.dropbox.com/s/s4f3i4dlvkzet7r/cut.mkv?dl=1

So, this cut show's 2.39 <=> 1.78 crop loop problem.

I can't reliably reproduce the initial transition partial flicker problem; if I can in another source then I'll post a cut of that.
That's a quite interesting sample, thanks! However, the problem only occurs if you start the movie and then directly seek to that position. Try the following:

1) Create an empty file named "ShowBlackBars" in the madVR folder, so you can see which rectangle madVR detects.
2) Start playback, wait until the Cinemascope AR is detected by madVR (green rectangle), then let video play for 10 seconds. Now this AR is stored as a "known good" AR.
3) Seek to some IMAX section, wait until madVR detects the AR (green rectangle), then let video play for 10 seconds. Now this AR is stored as a "known good" AR, too.
4) Now seek to the problematic timecode and play it through. It should play perfectly now.

Can you confirm the above? That means if you simply play the whole movie through from start to finish, the problem should not occur. I'll still look into this, maybe I can improve it.

About the flickering: Can you describe how it looks? Maybe it will be easier to describe with that green rect (ShowBlackBars, see above) active, and in fullscreen mode?

[dansrfe]

That's a quite interesting sample, thanks! However, the problem only occurs if you start the movie and then directly seek to that position. Try the following:

1) Create an empty file named "ShowBlackBars" in the madVR folder, so you can see which rectangle madVR detects.
2) Start playback, wait until the Cinemascope AR is detected by madVR (green rectangle), then let video play for 10 seconds. Now this AR is stored as a "known good" AR.
3) Seek to some IMAX section, wait until madVR detects the AR (green rectangle), then let video play for 10 seconds. Now this AR is stored as a "known good" AR, too.
4) Now seek to the problematic timecode and play it through. It should play perfectly now.

Can you confirm the above? That means if you simply play the whole movie through from start to finish, the problem should not occur. I'll still look into this, maybe I can improve it.

About the flickering: Can you describe how it looks? Maybe it will be easier to describe with that green rect (ShowBlackBars, see above) active, and in fullscreen mode?

I followed your steps and can confirm that the section in question disables the crop and remains at IMAX aspect until the transition to Cinemascope after the scene completes.

As for the flicker, the green rectangle transitions from Cinemascope to IMAX as expected however if stare directly at the center of the frame yet focus on the entire frame you should see some sort of "rapid vertical frame stretch and snap" that happens within a small fraction of a second.

IMAX to Cinemascope doesn't have the same issue however there is minor visible distortion near the center of the frame that vaguely looks like it's contracting.

It looks distinctly different from the transition that occurs without black bar cropping enabled.

[madshi]

I followed your steps and can confirm that the section in question disables the crop and remains at IMAX aspect until the transition to Cinemascope after the scene completes.
Just to be safe: So you agree that playback should be alright as long as you play the movie from start to finish?

As for the flicker, the green rectangle transitions from Cinemascope to IMAX as expected however if stare directly at the center of the frame yet focus on the entire frame you should see some sort of "rapid vertical frame stretch and snap back" that happens within a small fraction of a second.

It may just be an illusion that the brain is perceiving however it does look distinctly different from the transition that occurs without black bar cropping enabled.
Interesting. You don't have "notify media player about cropped black bars" activated, do you? If not, then I'm not sure where such a problem could come from. madVR does have to reconfigure the rendering algorithms if you use "crop black bars" when an AR change is detected, but that should not be visible, at least not if your queues are decently filled. If you get a chance to film this with a digicam, or some other way, I'd love to look into that.

[FreeFall]

madshi,

Sounds good, Thanks.

[aufkrawall]

madshi, we talked about this via PM: When doing ground truth comparisons, should the base image be downscaled linear light or gamma correct?
Linear light introduced aliasing into the lighttower example picture of leeperry. Now question is, is this always supposed to happen, so that linear light shouldn't be used? Or is this dependent on how the actual source material already has been downscaled?

[madshi]

I don't really know, to be honest. I suppose SuperRes should use the same method for downscaling as we used to downscale the base image. Currently madVR doesn't let you choose whether SuperRes uses linear light or not. I suppose that's an option I could add, but I'm not sure if I should. Currently madVR uses gamma light for SuperRes downscaling. So I suppose it would be better for ground truth comparisons to also use gamma light instead of linear light, when using madVR for now.

[aufkrawall]

Alright. There was that other example with a car having aliasing problems with SuperRes.
Could somebody link it again? Maybe it was as well due to linear light.

[madshi]

madVR v0.89.4 released

http://madshi.net/madVR.zip

* debug OSD now shows black bar, source and target rect details
* added "redraw" command so MPC-HC/MPC-BE can redraw subtitles in paused mode
* fixed: zero target rect / window size made madVR crash
* fixed: native DXVA accepted all formats, even when they weren't supported
* fixed: NNEDI3 OpenCL kernel was compiled even when using super-xbr or NEDI
* fixed: new NNEDI3 interop no longer requires win7 platform update
* fixed: sometimes NNEDI3 chroma doubling was incorrectly disabled
* fixed: crash when using NNEDI3 with old windowed mode render path
* fixed: option "if black bars change pick one zoom factor" had no effect
* fixed: two deadlock causes when switching between 576i and 1080i videos
* fixed: "keep bars visible if they contain subtitles" = "forever" didn't work
A bugfix release, before I do some more changes during the weekend.

[zvans18]

madVR v0.89.4 released

http://madshi.net/madVR.zip

* fixed: sometimes NNEDI3 chroma doubling was incorrectly disabled
A bugfix release, before I do some more changes during the weekend.

yeees, thank you very much! (also thank you for the profile scrollbar earlier) this is largely fixed for me, i only have one minor complaint/question. when luma and chroma quadrupling neuron counts differ (in my case both luma at 32, all 3 chroma at 16), it seems to just lump them into 'image' using the luma count on the OSD. first 4:2:0 chroma double reports fine.

as far as i can tell it's only on the OSD, render times are consistent with the settings i use.

maybe this is intended to reduce clutter as with quad/octupling there could be up to 9 different numbers reported? or just since it's bugfix? just makes it a little hard to tell at a glance.

[rbej]

madVR v0.89.4 released

http://madshi.net/madVR.zip

* debug OSD now shows black bar, source and target rect details
* added "redraw" command so MPC-HC/MPC-BE can redraw subtitles in paused mode
* fixed: zero target rect / window size made madVR crash
* fixed: native DXVA accepted all formats, even when they weren't supported
* fixed: NNEDI3 OpenCL kernel was compiled even when using super-xbr or NEDI
* fixed: new NNEDI3 interop no longer requires win7 platform update
* fixed: sometimes NNEDI3 chroma doubling was incorrectly disabled
* fixed: crash when using NNEDI3 with old windowed mode render path
* fixed: option "if black bars change pick one zoom factor" had no effect
* fixed: two deadlock causes when switching between 576i and 1080i videos
* fixed: "keep bars visible if they contain subtitles" = "forever" didn't work
A bugfix release, before I do some more changes during the weekend.

0.89.3 and 0.89.4 have bug. When i playing any movie in MPC-HC and quit aplication i have crash MPC. In 0.89.2 everything is ok. When i stop playing movie and quit is ok.

http://images70.fotosik.pl/1206/9897cca9dd90cbf4.jpg

[XRyche]

See the bold part in my quote. Just follow my instructions to the letter and it should work this time. The delay is not a problem. And one log should be good enough. Thanks.

Okay this is making me feel really stupid. I followed your instruction almost verbatim (except using v0.89.4 instead of v0.89.3) but I'm am not seeing a log on my desktop.
I uninstalled madVR using the uninstall.bat and deleted the madVR directory. I unzipped v0.89.4 to a madVR directory as is. I unzipped madVRXryche1.zip into the madVR directory replacing the madVR.ax. Opened the video in MPC-HC without using the activate debug mode.bat . No madVR log file.

This new build did fix the frame drop issue with no image with Super-xbr though.

[aufkrawall]

NNEDI3 chroma doubling with 2x image upscaling refinement now works, but it's not shown by the OSD.

[romulous]

* debug OSD now shows black bar, source and target rect details


Thank you for the return of the target rect details, madshi :)

[StinDaWg]

I have a 7850 and am using the latest version of madvr/amd driver/win 10 and my NNEDI3 render times are the exact same as before. No improvement at all. I'm using FSE mode with present 8 frames in advance. I read back the last few pages and don't see anyone with this issue. Any ideas?

[huhn]

i have this "issue" too with my AMD card. i haven't investigated it enough yet.

but i have very high reported rendertimes with nnedi3 with my nvidia card.

32 is ~40 ms 64 is ~40 ms and 128 is ~40ms at max power state.

[vivan]

Starting from v0.89.2 something has changed with subtitle rendering when using XySubFilter, text is blurred more (like if it was renderred at higher resolution and downscaled). Text stays sharp only when video is not scaled (640x360, 1280x720, 1920x1080 on 1366x768 display is not ok and look about the same, while 1366x768 on 1366x768 display is ok).
v0.89.1 (http://i.imgur.com/lS5NOyT.png)
v0.89.2 (http://i.imgur.com/Tq0hXd9.png)
v0.89.2 using internal subtitle renderer (http://i.imgur.com/UgLUnnf.png)

Video + subtitles (http://s000.tinyupload.com/index.php?file_id=51560301941058159474)

UPD: actually it's started from v0.89.0. When resizing the window with older version text snaps to pixels and is sharp, but staring from v0.89.0 it's possition is more accurate(?) which results in blurred text in most cases.

[madshi]

when luma and chroma quadrupling neuron counts differ (in my case both luma at 32, all 3 chroma at 16), it seems to just lump them into 'image' using the luma count on the OSD.
Will fix this for the next build.

NNEDI3 chroma doubling with 2x image upscaling refinement now works, but it's not shown by the OSD.
I'm not totally sure what you mean? If luma and chroma are both doubled (with the same settings), they're shown as "image doubling", instead of separate "luma doubling" + "chroma doubling". Although see above.

0.89.3 and 0.89.4 have bug. When i playing any movie in MPC-HC and quit aplication i have crash MPC. In 0.89.2 everything is ok. When i stop playing movie and quit is ok.

http://images70.fotosik.pl/1206/9897cca9dd90cbf4.jpg
Can you please click on "show bug report", then press Ctrl+C, then open notepad, press Ctrl+V, then upload the crash report somewhere (don't attach it to this forum) for me to look at. Thanks.

Okay this is making me feel really stupid. I followed your instruction almost verbatim (except using v0.89.4 instead of v0.89.3) but I'm am not seeing a log on my desktop.
I uninstalled madVR using the uninstall.bat and deleted the madVR directory. I unzipped v0.89.4 to a madVR directory as is. I unzipped madVRXryche1.zip into the madVR directory replacing the madVR.ax. Opened the video in MPC-HC without using the activate debug mode.bat . No madVR log file.

This new build did fix the frame drop issue with no image with Super-xbr though.
This might have been my fault, maybe I send you a bad/wrong build, I'm not sure. In any case, please forget about the special build. Instead just send me a debug log with v0.89.4, that will serve the same purpose. Thanks!

I have a 7850 and am using the latest version of madvr/amd driver/win 10 and my NNEDI3 render times are the exact same as before. No improvement at all. I'm using FSE mode with present 8 frames in advance. I read back the last few pages and don't see anyone with this issue. Any ideas?
The improvement is mostly for those who had slower times caused by the PCIe interop. If your PC has a very fast PCIe bus, and if you're using high neuron counts then the improvement is probably very small for you. That's not really an "issue".

but i have very high reported rendertimes with nnedi3 with my nvidia card.

32 is ~40 ms 64 is ~40 ms and 128 is ~40ms at max power state.
You're saying you have the same render times regardless of how many neurons you're using? That sounds very strange! What happens if you go back to e.g. v0.88.21, do you have better render times with your NVidia GPU there?

Starting from v0.89.2 something has changed with subtitle rendering when using XySubFilter, text is blurred more (like if it was renderred at higher resolution and downscaled). Text stays sharp only when video is not scaled (640x360, 1280x720, 1920x1080 on 1366x768 display is not ok and look about the same, while 1366x768 on 1366x768 display is ok).
v0.89.1 (http://i.imgur.com/lS5NOyT.png)
v0.89.2 (http://i.imgur.com/Tq0hXd9.png)
v0.89.2 using internal subtitle renderer (http://i.imgur.com/UgLUnnf.png)

Video + subtitles (http://s000.tinyupload.com/index.php?file_id=51560301941058159474)

UPD: actually it's started from v0.89.0. When resizing the window with older version text snaps to pixels and is sharp, but staring from v0.89.0 it's possition is more accurate(?) which results in blurred text in most cases.
Ah, thanks! Will have a look at this.

[Siso]

An odd bug or something: lav 0.66 + madvr 0.89.2,0.89.3 and 0.89.4 sometimes missdetect primaries which are BT.709 with SMPTE C.

[rbej]

0.89.3 and 0.89.4 have bug. When i playing any movie in MPC-HC and quit aplication i have crash MPC. In 0.89.2 everything is ok. When i stop playing movie and quit is ok.

http://images70.fotosik.pl/1206/9897cca9dd90cbf4.jpg


Can you please click on "show bug report", then press Ctrl+C, then open notepad, press Ctrl+V, then upload the crash report somewhere (don't attach it to this forum) for me to look at. Thanks.

http://pastebin.com/pbc5qjpT

[James Freeman]

To crop or not to crop black bars?

[madshi]

An odd bug or something: lav 0.66 + madvr 0.89.2,0.89.3 and 0.89.4 sometimes missdetect primaries which are BT.709 with SMPTE C.
A short sample would be helpful.

http://pastebin.com/pbc5qjpT
Thanks. Could you also create a debug log from this situation? That would be most helpful!

To crop or not to crop black bars?
It saves performance, but cuts off TV station logos and hard coded subtitles. Your choice.

[StinDaWg]

The improvement is mostly for those who had slower times caused by the PCIe interop. If your PC has a very fast PCIe bus, and if you're using high neuron counts then the improvement is probably very small for you. That's not really an "issue".
I have PCIe 2.0 and am using 16 neurons on 720p60->1080p60. Was hoping to see an improvement after your initial post of "huge gains" on AMD but that is not the case.

Oh well. :)

[Siso]

A short sample would be helpful.

I hope it will help :)

http://www24.zippyshare.com/v/hFoQpbqw/file.html

[Sunset1982]

@madshi:

Feature request:

Would be nice to see what build/version of madvr actually is running. If that would be shown on osd that would be good for error hunting. Everyone could easyly see if he is running the latest version or - if he updated the build - that the update worked and new version is running good. That came into my mind because you saw on some error logs that not the actual/userwanted version was running on the system. With this feature all guys could easily see what version is running.

[Siso]

On a side note I've noticed something strange to me, when using xysubfilter latest beta, the rendering times in madvr are normal since the first show of subtitles on screen, after that the rendering times got higher with 1-2ms, even with "render to original video size" option selected, is that normal?