[madshi]

Originally Posted by XRyche

No if I use any type of image doubling (NNEDI3,NEDI,Super-xbr) I get the massive frame-skipping before an image actually appears.

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.

Originally Posted by XRyche

madshi, here's the log for the custom debug build: https://www.mediafire.com/?hujbvatwmw0rj6k . It's even compressed :P . I did notice that there was a slight pause (3 seconds at most) when I started the file which starts in windowed mode when I initially played the file. When I played it again in debug mode there was no pause until I went to FSE mode than there was the typical 350 fps skip.

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!

Originally Posted by kingfire

I updated my graphics drivers to the latest version using DDU. Didn't help. Tried re-installing MadVR but also this didn't help.

Did NNEDI3 ever work for you? This looks like either a GPU driver bug or a hardware problem to me. I'm sorry, I don't think there's anything I can do here... You could try reporting this to your GPU's support forums.

Originally Posted by QBhd

Now along comes this spectacular version of madVR! First I just updated madVR and ran it as is. WOW! GPU usage dropped from 93% to 66% HUGE improvement. So I bumped up one of the three NNEDI3 settings from 32 neurons to 64 (yes I do chroma and I do both in luma) and this pushed the GPU up to 78% (couldn't get any more neurons even though there is still room). Nice little bonus, more neurons is always better. So I figured with this headroom I should be able to run the latest AMD drivers without having to dial back my neuron counts. And sure enough it worked... GPU usage did go up as expected (78% up to 85%) so 13.12 is still the best performing AMD driver when it come to madVR. However, the magic you did madshi, does allow users like me to upgrade driver without worrying about reducing settings in madVR. HUGE kudos for that! Also, D3D11 now also works flawlessly with PotPlayer, yet another nice little bonus.

Great to hear! D3D11 now working, is that due to the new madVR build? Or due to the AMD driver update? Or was both needed to make that work? Just for my interest, in case you know...

Originally Posted by huhn

http://filehorst.de/d/bAHCafIb

steps to reproduce from madVR default settings:
disable fullscreen exclusive mode.
enable nnedi3 64 neurons for luma.
play a 720p source in fullscreen on a 1080p screen.

Hmmmm... I can see that in the "good" log NNEDI3 processing takes about 15ms per frame. The other render steps for each video frame are all < 3ms each. In the "bad" log it's exactly the same way - until smooth motion FRC kicks in. Then suddenly NNEDI3 processing takes 25ms per frame, and the last processing step takes 10ms. I'm not sure why it's sometimes this way and sometimes the other way. It's simply the GPU which seems to take more time doing the rendering. Can't see anything in the logs which would point to madVR doing anything differently. It *could* be somewhat related to smooth motion FRC, but I'm not sure about that. Smooth motion itself doesn't seem to need a lot of time in either case.

Originally Posted by Hprd

Ok, here are some logs that might help.

https://www.dropbox.com/s/0ud1gfzukm...0logs.zip?dl=0

What problem are the logs for? What exactly did you capture there? I need to know what to look for, otherwise it's just millions of characters in a text file, and I wouldn't know what to do with it.

Originally Posted by dansrfe

What is the quality difference between applying SuperRes before/after image upscaling? Is this difference only visible when upscaling 2x or more?

Huh? SuperRes is always *after* upscaling. Not sure what you mean?

Originally Posted by FreeFall

Yeah, you told me not to use stretch to window, I'll try to explain things a bit better. Tested using Windows 7 64bit Pro and Mpc-hc 1.7.9 (x64).

Using the keep black bars visible if they contain subtitles option and setting it to forever doesn't work for me, the video is still being cropped (osd shows 720*450). Changing it to 90min or any other setting lower works without any problems, using the DVD sample I uploaded and a handful of disc's and videos I have.

The reason I use stretch to window on that Blu-ray sample is because in full screen mode touch window from the inside does not remove the pillar boxing, using stretch to window does which is exactly what I want.

These are the settings I use:

automatically detect hard coded black bars.
notify media player about black bars, no more than once every 2 sec.
crop black bars.

What I was asking for is the ability to simply crop the black bars without doing anything else, no aspect ratio correction. The same as using Avisynth to crop before re-encoding or on the fly via FFDshow. As I said before it's not a big deal but would come in handy for people like me who don't mind breaking the AR and stretching the image a little.

The advantage this method has is that you can remove the black bars and keep the subtitles intact, here is an example using the DVD sample.

madVR, touch window from inside:
https://www.dropbox.com/s/q4ixihzrfj...0crop.jpg?dl=0

re-encode cropped to 720*450, stretch to window:
https://www.dropbox.com/s/ypia193l5b...0crop.jpg?dl=0

Hmmm... Now I'm a bit confused. I had originally thought that those subtitles were burned into the video image. But after checking again that's not actually the case. It seems the DVD Navigator outputs a subtitle stream and "somebody" draws them to the image. I'm not even sure who does that exactly.

Does anybody know which software (internal subtitle renderer, external subtitle renderer, LAV Video Renderer, whatever) draws subtitles output by the DVD Navigator onto the video image - and at what time (before madVR gets the images or after or something)?

Originally Posted by chros

2. About my NNEDI3 chroma upsampling crash: I just refreshed to newest vga drivers, doing a clean install (see my signature):
- the crash is still there
- Windowed Overlay mode still isn't available with this combination

Looked at your log. The crash should be solved in the next build, in any case. However, it seems you're using the old exclusive mode path (meaning: "present several frames in advance" unchecked). Is that correct? Doing so means that madVR cannot share the render device, which also means the new D3D11 OpenCL interop cannot be used, nor Windowed Overlay. You'll have to activate "present several frames in advance" in the FSE settings, to make the new NNEDI3 work, and Windowed Overlay.