madVR - high quality video renderer (GPU assisted)

[madshi]

Ah, yes. It seems like a bug in conjunction with upscaling refinement after each 2x upscaling step.
Ok, one more thing to fix.

you get your freeze report and logs soon. it takes a min or 2 after closing the player until i get an freeze report on my desktop so i have a "couple" more on my desktop now.

will do it cleanly now.
Thanks.

[huhn]

here you go

http://filehorst.de/download.php?file=bIFsEeDx

[madshi]

Hmmmm... Thanks! For some reason the log is empty, though. And the freeze report doesn't contain any information about LAV at all, which is rather weird. I'm not sure what went wrong there. Are you sure you downloaded the correct version of the LAV debug symbols? If so, maybe you could try creating another freeze report with 32bit MPC-HC? Maybe that works better than 64bit, I'm not sure...

[XRyche]

It's not really a problem, just wondering since compression works by far best on text files like that.

So, I had a quick look at your debug log, but I'm not totally sure what to look for. I can see that it contains about 30 seconds of runtime. So which was the problem exactly which you captured in this debug log?




I ran MPC-HC until I got a video image to show on screen. I assumed it would show the inordinately long wait time and the weird emboss/brownish effect with NNEDI3.

Also, when I use NNEDI3 for chroma upsampling the image is completely green. I can still see the image but it's all in green. This is even when not using image doubling.

If you want me to run the player for 5 minutes when using the debugging I have no problem with doing that. I won't be able to do it until I get home in about 3 hours or so though.

[huhn]

Hmmmm... Thanks! For some reason the log is empty, though. And the freeze report doesn't contain any information about LAV at all, which is rather weird. I'm not sure what went wrong there. Are you sure you downloaded the correct version of the LAV debug symbols? If so, maybe you could try creating another freeze report with 32bit MPC-HC? Maybe that works better than 64bit, I'm not sure...

after i tried to delete the log it was still in use of MPC-hc so i guess that's why it is blank but i looked into it before...

for the lavfilter version i used stable 0.66 and the linked PDB in the forum post with 0.66 in the zipped folder name.

i will try 32 bit now and i install lavfilter to another folder program files under windows 10 has some heavy right "problems".


edit: v2: http://filehorst.de/d/bdntmfqu

i put content from LAVFilters-0.66-symbols.zip in LAV Filters\x86 and i made sure mpc-hc 32 used that lavfilter version. the freeze report doesn't look any different to me than the last one.

there is content in the log.

[madshi]

settings.bin (https://www.dropbox.com/s/kkvdsjstrwziwrb/settings.bin?dl=1)

Latest 0.66. Reproduced with dxva2n and avcodec (SW).

I am attaching my setup.xml which you have to copy to the DVBViewer configuration folder (http://de.dvbviewer.tv/wiki/Konfigurationsverzeichnis). But I don't think that it will make any difference.

setup.xml (https://www.dropbox.com/s/arwfm9d7oil1w6e/setup.xml?dl=1)

Intel Ivy Bridge HD 4000 graphics @ 1080p50.

Win7 32-Bit.
Ok, I've used your exact madVR + DVBViewer settings, HD4000 GPU @ 1080p60 (my computer monitor doesn't support 50Hz), but Windows 8.1 x64. Unfortunately, I wasn't able to reproduce the problem. I let it switch back and forth like 30 times without any problems in FSE mode. I had to use the default audio renderer instead of ReClock (I don't have ReClock installed), but I doubt that was the key difference.

So now I think the best course of action is the following:

Step 1: We need to find the exact madVR build which introduced the problem. From your earlier posts it seems the problem occurs with v0.89.2, but not with v0.88.16, right? So some build in between must have introduced the problem. Could you try the last 88 build v0.88.21? If that build works for you, probably v0.89.0 has introduced the problem. Could you double check that with v0.89.0 then, just to confirm? If the problem also occurs with v0.88.21, can you check the versions in between v0.88.21 and v0.88.16 to find the exact version which introduced the problem? The most likely candidates would then be v0.88.17, v0.88.20 or v0.88.21.

Step 2: I would then create some test builds which are somewhere between the last build that still works and the first build which doesn't work, anymore, so we can isolate the exact change in my code which introduced the problem.

This is a painful way of debugging, but I'm out of other ideas. I hope for you it wouldn't be too much effort, because I don't need any more logs or reports or anything. Just a "yes/no" for each test build. Would that be ok for you?

The previous madVR builds are all available for download here:

http://www.videohelp.com/software/madVR/old-versions#download

Usually you can just overwrite the files, no need to uninstall/reinstall.

Thanks!!

I ran MPC-HC until I got a video image to show on screen. I assumed it would show the inordinately long wait time and the weird emboss/brownish effect with NNEDI3.

Also, when I use NNEDI3 for chroma upsampling the image is completely green. I can still see the image but it's all in green. This is even when not using image doubling.
Ah ok, so the long delay is right at the start of playback, correct? How long did it roughly take? Knowing that would help me to interpret the log better. Did anything change between v0.89.2 and v0.89.3 for you?

FWIW, have you tried reinstalling the GPU driver or installing a different/newer driver version?

i put content from LAVFilters-0.66-symbols.zip in LAV Filters\x86 and i made sure mpc-hc 32 used that lavfilter version. the freeze report doesn't look any different to me than the last one.
This looks much more useful - thanks! :)

@nevcairiel, are you listening? From the freeze report it doesn't look like madVR is directly involved. Could you check the thread callstacks? I've copied the most interesting here. Maybe you can see what's wrong? Could it be that threads $e34 and $175c are blocking each other? Or maybe cuvidDecodePicture is simply frozen?

From the madVR debug log it seems that the decoder simply stops sending frames at some point, for unknown reasons...

date/time : 2015-09-23, 19:39:53, 991ms
operating system : Windows 10 x64 build 10240
free disk space : (C:) 65.12 GB
display mode : 1920x1080, 32 bit
allocated memory : 387.14 MB
largest free block : 1.97 GB
executable : mpc-hc.exe

thread $e34:
7079307f +00f nvcuvid.dll cuvidDecodePicture
70bd50e3 +0d3 LAVVideo.ax cuvid.cpp 854 +43 CDecCuvid.HandlePictureDecode
7078f284 +024 nvcuvid.dll cuvidParseVideoData
70bd5b7c +1ec LAVVideo.ax cuvid.cpp 1168 +62 CDecCuvid.Decode
70bd1bef +10f LAVVideo.ax quicksync.cpp 76 +28 CDecBase.Decode
70be0700 +350 LAVVideo.ax decodethread.cpp 380 +122 CDecodeThread.ThreadProc
70c6d514 +034 LAVVideo.ax wxutil.cpp 124 +8 CAMThread.InitialThreadProc
70c75780 +018 LAVVideo.ax threadex.c 376 +13 _callthreadstartex
70c758a6 +077 LAVVideo.ax threadex.c 354 +55 _threadstartex
75ce3742 +022 KERNEL32.DLL BaseThreadInitThunk

thread $e28:
75068d03 +93 KERNELBASE.dll WaitForSingleObjectEx
75068c5d +0d KERNELBASE.dll WaitForSingleObject
70c6d4c8 +08 LAVVideo.ax wxutil.cpp 183 +1 CAMThread.GetRequest
70be9236 +16 LAVVideo.ax lavvideo.cpp 2144 +4 CLAVControlThread.ThreadProc
70c6d514 +34 LAVVideo.ax wxutil.cpp 124 +8 CAMThread.InitialThreadProc
70c75780 +18 LAVVideo.ax threadex.c 376 +13 _callthreadstartex
70c758a6 +77 LAVVideo.ax threadex.c 354 +55 _threadstartex
75ce3742 +22 KERNEL32.DLL BaseThreadInitThunk

thread $175c:
75068d03 +093 KERNELBASE.dll WaitForSingleObjectEx
75068c5d +00d KERNELBASE.dll WaitForSingleObject
70be0108 +158 LAVVideo.ax decodethread.cpp 186 +35 CDecodeThread.Decode
70be7a34 +134 LAVVideo.ax lavvideo.cpp 1290 +31 CLAVVideo.Receive
70c6e979 +059 LAVVideo.ax transfrm.cpp 763 +8 CTransformInputPin.Receive
70c674e6 +016 LAVVideo.ax decssinputpin.cpp 375 +2 CDeCSSTransformInputPin.Receive
723a5559 +019 LAVSplitter.ax amfilter.cpp 2695 +8 CBaseOutputPin.Deliver
723777f0 +540 LAVSplitter.ax outputpin.cpp 535 +96 CLAVOutputPin.DeliverPacket
77a48c0a +00a ntdll.dll NtWaitForSingleObject
75068d03 +093 KERNELBASE.dll WaitForSingleObjectEx
723771b9 +1f9 LAVSplitter.ax outputpin.cpp 412 +38 CLAVOutputPin.ThreadProc
723a890a +02a LAVSplitter.ax wxutil.cpp 117 +1 CAMThread.InitialThreadProc
723a8914 +034 LAVSplitter.ax wxutil.cpp 124 +8 CAMThread.InitialThreadProc
723ac2e8 +018 LAVSplitter.ax threadex.c 376 +13 _callthreadstartex
723ac40e +077 LAVSplitter.ax threadex.c 354 +55 _threadstartex
75ce3742 +022 KERNEL32.DLL BaseThreadInitThunk

thread $1764:
750713c2 +092 KERNELBASE.dll SleepEx
7507131a +00a KERNELBASE.dll Sleep
72376dea +0aa LAVSplitter.ax outputpin.cpp 341 +12 CLAVOutputPin.QueuePacket
7237ba8e +2be LAVSplitter.ax lavsplitter.cpp 844 +62 CLAVSplitter.DeliverPacket
7237b75c +29c LAVSplitter.ax lavsplitter.cpp 741 +59 CLAVSplitter.ThreadProc
723a890a +02a LAVSplitter.ax wxutil.cpp 117 +1 CAMThread.InitialThreadProc
723a8914 +034 LAVSplitter.ax wxutil.cpp 124 +8 CAMThread.InitialThreadProc
723ac2e8 +018 LAVSplitter.ax threadex.c 376 +13 _callthreadstartex
723ac40e +077 LAVSplitter.ax threadex.c 354 +55 _threadstartex
75ce3742 +022 KERNEL32.DLL BaseThreadInitThunk

modules:
00860000 mpc-hc.exe 1.7.9.0 C:\Program Files (x86)\MPC HomeCinema
05910000 avcodec-lav-56.dll 56.57.100.0 C:\lav filter\LAV Filters\x86
4a400000 madVR.ax 0.89.3.0 C:\madVR

[CiNcH]

Would that be ok for you?
Sure... let's see... 0.88.17 seems fine with respect to the lockup issue. It just suffers from weird flickering all the time. 0.88.18 then produced the lockup (just like 0.88.21 obviously...).

[huhn]

there is an other nnedi3 issue.

render queue drops down 2-3 and render times getting higher easily to 40-42 ms. there are no frame drops.

here 2 screens from the same file with the same settings:

normal: http://abload.de/img/anothernnedi3issue8arbf.png
problem: http://abload.de/img/anothernnedi3issue291rz8.png

this is usually created after a seek sometimes from the start.

i had a VRAM issue that's why i don't use 8 present frames in advance

[aufkrawall]

So far, NNEDI3 has been totally stable here with the new versions, apart from that small upscaling refinement bug.
12 frames prerendered and D3D11 also seem to be totally fine here so far in windowed mode on Win 10 (GTX 980, 355.98).

[XRyche]

Ah ok, so the long delay is right at the start of playback, correct? How long did it roughly take? Knowing that would help me to interpret the log better. Did anything change between v0.89.2 and v0.89.3 for you?

FWIW, have you tried reinstalling the GPU driver or installing a different/newer driver version?




Yes the long delay is at the very start of playback. I ban hear the audio playing just fine but I just get a black screen instead of video. When the video does show it is completely in sync with the audio.

The exact time I haven't taken notice of but, for 23.9 fps video it skips about 350 fps on average. For 30 fps videos its skips 450 to 500 fps on average.

Absolutely nothing changed between v0.89.2 and v0.89.3.

I did try reinstalling the driver with Display Driver Uninstaller when this first started happening when I upgraded from Windows 8.1 to Windows 10. When AMD came out with a beta driver for windows 10 just 2 weeks ago or so I switched to that using Display Driver Uninstaller. No of this made a difference either.

[madshi]

Sure... let's see... 0.88.17 seems fine with respect to the lockup issue. It just suffers from weird flickering all the time. 0.88.18 then produced the lockup (just like 0.88.21 obviously...).
Oh, that seems almost too easy to be true! v0.88.18 only has rather few changes compared to v0.88.17. I'll make a few test builds in between... :) I hope this is the same cause of the lockup we're having with v0.89.3. We'll see...

there is an other nnedi3 issue.

render queue drops down 2-3 and render times getting higher easily to 40-42 ms. there are no frame drops.

here 2 screens from the same file with the same settings:

normal: http://abload.de/img/anothernnedi3issue8arbf.png
problem: http://abload.de/img/anothernnedi3issue291rz8.png

this is usually created after a seek sometimes from the start.

i had a VRAM issue that's why i don't use 8 present frames in advance
Not sure what to say about that. Don't really have enough information. Could you try creating two debug logs: One which has the faster render times, and one which has the slower render times? For the slower render times it would be great if it would be right from the start, that would make it easier for me to interpret the logs.

So far, NNEDI3 has been totally stable here with the new versions, apart from that small upscaling refinement bug.
12 frames prerendered and D3D11 also seem to be totally fine here so far in windowed mode on Win 10 (GTX 980, 355.98).
Good to hear!

Yes the long delay is at the very start of playback. I ban hear the audio playing just fine but I just get a black screen instead of video. When the video does show it is completely in sync with the audio.

The exact time I haven't taken notice of but, for 23.9 fps video it skips about 350 fps on average. For 30 fps videos its skips 450 to 500 fps on average.
Ok, I see what it is: madVR compiles the NNEDI3 OpenCL kernel at startup. And that takes about 14 seconds on your PC. That's ok, but it should only happen once. The compiled kernel should then be stored in your registry. But for some reason it seems that madVR recompiles the kernel every time. I'm not sure why. Could you check whether there's a folder named "HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL" in your registry? What happens if you delete it and then play another video with madVR. Is it recreated after those 15 seconds waiting time? Try checking the registry access rights. Maybe something weird happened with the access rights and madVR can't write to the registry?

[AndreaMG]

I made some tests and found out that the freeze issue under WIN10 in my case is caused by two things:
1) LAV CUVID + MadVR NNEDI3 chroma upscaling
or
2) LAV CUVID + SVP OPEN CL

[madshi]

I made some tests and found out that the freeze issue under WIN10 in my case is caused by two things:
1) LAV CUVID + MadVR NNEDI3 chroma upscaling
or
2) LAV CUVID + SVP OPEN CL
Can you try "LAV CUVID + SVP OPEN CL" with a different video renderer, to check whether madVR is involved in this freeze at all?

[madshi]

Sure... let's see... 0.88.17 seems fine with respect to the lockup issue. It just suffers from weird flickering all the time. 0.88.18 then produced the lockup (just like 0.88.21 obviously...).
Which ones of these lockup?

http://madshi.net/madVRcinch1.rar

Thanks!

[XRyche]

Ok, I see what it is: madVR compiles the NNEDI3 OpenCL kernel at startup. And that takes about 14 seconds on your PC. That's ok, but it should only happen once. The compiled kernel should then be stored in your registry. But for some reason it seems that madVR recompiles the kernel every time. I'm not sure why. Could you check whether there's a folder named "HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL" in your registry? What happens if you delete it and then play another video with madVR. Is it recreated after those 15 seconds waiting time? Try checking the registry access rights. Maybe something weird happened with the access rights and madVR can't write to the registry?

I actually tried deleting that exact folder just recently, since I read someone suggested doing just that for a similar issue. It didn't make a difference.

How would one go about checking registry access rights? What should i look for? If the administrator account has full access rights (I use my home PC with only the Administrator account) or if madVR itself has read/write access rights?

[madshi]

I actually tried deleting that exact folder just recently, since I read someone suggested doing just that for a similar issue. It didn't make a difference.
Is it recreated when you delete it and run madVR afterwards?

[AndreaMG]

Can you try "LAV CUVID + SVP OPEN CL" with a different video renderer, to check whether madVR is involved in this freeze at all?

LAV CUVID + SVP OPEN CL + EVR = Deadly Freeze

so I guess (at least this time :)) it's not MadVR's fault.

I posted the issue in SVP forum by the way.

[madshi]

LAV CUVID + SVP OPEN CL + EVR = Deadly Freeze

so I guess (at least this time :)) it's not MadVR's fault.

I posted the issue in SVP forum by the way.
Ha! Thanks... :)

It seems that any kind of OpenCL freezes in combination with LAV CUVID. I think the only one who can do something about it is nevcairiel, because neither SVP nor madVR know whether CUVID is active or not, nor can we disable it.

Ultimately it's NVidia's fault, though, that's very obvious now.

[CiNcH]

Which ones of these lockup?

http://madshi.net/madVRcinch1.rar

madVR_framequeue already locks up. To be sure i tried again original 0.88.17 and it also locked up this time. So it must be between 88.16 and 88.17.

[AndreaMG]

Ha! Thanks... :)

It seems that any kind of OpenCL freezes in combination with LAV CUVID. I think the only one who can do something about it is nevcairiel, because neither SVP nor madVR know whether CUVID is active or not, nor can we disable it.

Ultimately it's NVidia's fault, though, that's very obvious now.

You're welcome Madshi. I don't think Nev will do anything because i recall he (rightfully) said in his thread it's NVIDIA's fault...

[madshi]

madVR_framequeue already locks up. To be sure i tried again original 0.88.17 and it also locked up this time. So it must be between 88.16 and 88.17.
Ouch. That's the worst case scenario. :( Those changes in 88.17 to render in paused and stopped mode, and for low latency OSD really do bite me in the a... Unfortunately they're very important for some media players, so I can't really remove them. Will have to invest some work to create test builds between 88.16 and 88.17, but not today, anymore.

[XRyche]

Is it recreated when you delete it and run madVR afterwards?

Yes it is recreated.

[madshi]

Yes it is recreated.
Ok, please use this debug build to create a new debug log and upload it for me:

http://madshi.net/madVRXRyche1.rar

This build will not do anything differently, just the debug log will give me some more information.

Just to double check: When disabling NNEDI3 everywhere (both chroma upscaling and image doubling) all problems are gone, right?

[huhn]

just asking XRyche did you changed the folder for madVR yet? to something like c:/madvr ?

the Program Files on windows 10 takes security way to serious...
i guess worth a try.

[XRyche]

Ok, please use this debug build to create a new debug log and upload it for me:

http://madshi.net/madVRXRyche1.rar

This build will not do anything differently, just the debug log will give me some more information.

Just to double check: When disabling NNEDI3 everywhere (both chroma upscaling and image doubling) all problems are gone, right?

No if I use any type of image doubling (NNEDI3,NEDI,Super-xbr) I get the massive frame-skipping before an image actually appears. NNEDI3 in image doubling looks like an brownish embossed effect and NNEDI3 for chroma upsampling produces a green image regardless of whether it is used in conjunction with frame doubling or not.

I will run your special build after I try huhn's suggestion because Windows 10 is seriously paranoid with it's security (although they have no problem with keeping track of you if they(Microsoft) are doing the tracking.).

just asking XRyche did you changed the folder for madVR yet? to something like c:/madvr ?

the Program Files on windows 10 takes security way to serious...
i guess worth a try.

As I told madshi I'll try it. I'm willing to try anything at this point.

[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.

huhn, unfortunately moving the madVR folder to even an entirely different drive didn't make a difference. I made sure I uninstalled and deleted the madshi entry in the registry before I installed madVR from it's new location.

[huhn]

huhn, unfortunately moving the madVR folder to even an entirely different drive didn't make a difference. I made sure I uninstalled and deleted the madshi entry in the registry before I installed madVR from it's new location.

was very unlikely anyway.

[kingfire]

Then it's probably either a GPU driver bug, or a GPU hardware issue. Maybe using a different GPU driver version helps?

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

[QBhd]

Let me start off with some history. First, for the longest time the best performing AMD driver has been 13.12. Second, I have never been able to use D3D11 in any form, it worked, but as soon as I would pause PotPlayer, it would flash and queues would fall to zero and never recover, oddly it would not report dropped frames, but the video would stutter like mad because of the empty queues. So I have been stuck on a very old driver (if I wanted to push NNEDI3 to the max) and stuck with D3D9 (not that it really mattered when it comes to quality). I continued doing updates to both driver and madVR and always ended up rolling back features/driver.

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.

I just wanted to say a big Thank You!

As for the missing screen config option when using a digital flat panel. I could see there being a use to including it. As I mentioned above, I have an old Plasma with rectangular pixels (1024x768). I tested out the screen config (set it to projector to expose the settings) and setting the anamorphic lens to 4/3 did work flawlessly to compensate for these rectangular pixels. I personally don't need this, since I know how to set PotPlayer's Output Device to "TV-Out 16:9" to fix any mis-matched aspect ratios. But maybe others don't know this or their player won't allow this. It could be useful, but of course the choice is yours :)

Anyway huge Kudos to making madVR more efficient!

QB

EDIT: Should have mentioned this is all on Windows 8.1 x64

[leeperry]

WOW! GPU usage dropped from 93% to 66% HUGE improvement.
on W7 or W8?

[huhn]

Not sure what to say about that. Don't really have enough information. Could you try creating two debug logs: One which has the faster render times, and one which has the slower render times? For the slower render times it would be great if it would be right from the start, that would make it easier for me to interpret the logs.

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.

[Hprd]

Ok, here are some logs that might help.

https://www.dropbox.com/s/0ud1gfzukmadtmh/madvr%20logs.zip?dl=0

[QBhd]

on W7 or W8?

Sorry, guess I should have mentioned that... Windows 8.1 x64

QB

[dansrfe]

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

[TheElix]

Let me start off with some history. First, for the longest time the best performing AMD driver has been 13.12. Second, I have never been able to use D3D11 in any form, it worked, but as soon as I would pause PotPlayer, it would flash and queues would fall to zero and never recover, oddly it would not report dropped frames, but the video would stutter like mad because of the empty queues.Wow... I'd had the same flashing as you had since the implementation of D3D11. I will try the new build today. I hope it works. Windows 10 x64 here.

[FreeFall]

madshi,

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. :devil:

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/q4ixihzrfj1g881/madVR%20crop.jpg?dl=0

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


Thanks.

[chros]

3. 1 more thing popped in my mind about cropped black bars and profiling by size :) : will this work/detect screen changes on the fly? :)
Yes, it should.

1. Indeed, indeed :) That's truly amazing!!! :)

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

Thanks for your awesome work!!!! :thanks:

[madshi]

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.

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!

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.

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...

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.

Ok, here are some logs that might help.

https://www.dropbox.com/s/0ud1gfzukmadtmh/madvr%20logs.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.

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?

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. :devil:

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/q4ixihzrfj1g881/madVR%20crop.jpg?dl=0

re-encode cropped to 720*450, stretch to window:
https://www.dropbox.com/s/ypia193l5b2xzbs/Avisynth%20crop.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)?

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.

[amayra]

i have a sample problem i lose my calibrate for my monitor after use dx11

[ryrynz]

Is the window touching text in the OSD only supposed to update when the window is changed like it does ATM?

[FreeFall]

I think Lav Video Decoder renders the subtitles, you'll have to ask nevcairiel for more information.

[ryrynz]

sent a bug report via madvr. 0.89.3 with mpc-be is not showing video & crashing.

[Hprd]

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.

The issue with freezing when enabling image doubling and NVidia CUVID is enabled. (or is this solved by now?)

[leeperry]

BTW whenever a new mVR build is released and I want to open its control panel I have to wait quite a bit(around 5/10 secs) for a window to ask me whether I want to authorize it to run on my system, I get the same window with other .exe's but it goes a lot faster. Am I the only one? UAC is disabled for that matter and I'm on W7SP1.

[clsid]

@madshi
Instead of re-naming the files when switching to release/debug build, you should just register the desired file. It will then replace the existing registration. Should result in less confusion I think.

[chros]

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.
Thanks, and you're right, I'm using old exclusive mode 'cause it's way faster (at least it was) than all the others. (I'll test this tonight.)
It's a sad news: can't you do anything about it? (using these 2 feature as well in old exclusive) It's not a problem if not, but it would be nice to have them. Thanks!

[QBhd]

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...

I am fairly certain that I went through the new madVR first before wiping the old AMD driver and installing the new one. So I am confident that it was this latest madVR that finally fixed the D3D11 issues I had. With that said, I could do a quick and dirty rollback of madVR to see if this is indeed the case.

QB

[huhn]

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.

there must be something wrong with how rendertimes are calculated here an example:
http://abload.de/img/rendertimescalculatio6nq9a.png

i mean AVG rendertimes of ~17.5 ms while playing 60 fps without frame drops and MAX rendertimes are lower than AVG...

would a log without SM of any use?

[kasper93]

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)?

If DVD Navigator is used subtitles are burned by LAV Video Decoder, before it gets to madVR. If DVD Navigator is not used subtitles are rendererd by ISR.

[madshi]

i have a sample problem i lose my calibrate for my monitor after use dx11
Is the window touching text in the OSD only supposed to update when the window is changed like it does ATM?
I'm not sure what the two of you mean. Can you clarify?

I think Lav Video Decoder renders the subtitles, you'll have to ask nevcairiel for more information.
You're right. I'm talking to nevcairiel, trying to find a solution. Not sure yet if he's willing, though.

sent a bug report via madvr. 0.89.3 with mpc-be is not showing video & crashing.
Hmmm... That looks pretty bad. The NVidia OpenCL driver seems to crash when releasing some resources. It could be some buffer overrun bug caused by anyone (including madVR), or it could be a "simple" bug in the NVidia driver. Does this happen 100% every time? Have you tried installing a different GPU driver version?

The issue with freezing when enabling image doubling and NVidia CUVID is enabled. (or is this solved by now?)
AndreaMG has proven that it's not madVR's fault, but a general incompatability of CUVID with OpenCL on Windows 10, which also occurs when using EVR.

BTW whenever a new mVR build is released and I want to open its control panel I have to wait quite a bit(around 5/10 secs) for a window to ask me whether I want to authorize it to run on my system, I get the same window with other .exe's but it goes a lot faster. Am I the only one? UAC is disabled for that matter and I'm on W7SP1.
I haven't seen that here yet. No idea where it comes from. FWIW, if I removed the digital certificate, it would very likely be exactly the same, or even worse.

Instead of re-naming the files when switching to release/debug build, you should just register the desired file. It will then replace the existing registration. Should result in less confusion I think.
That's not a bad idea at all. The problem is that some users seemed to have problems with the "install.bat" and "uninstall.bat". So your suggestion might be the more logical and less confusing solution, but I fear that it might be less reliable. I'm not totally sure, though...

Thanks, and you're right, I'm using old exclusive mode 'cause it's way faster (at least it was) than all the others. (I'll test this tonight.)
It's a sad news: can't you do anything about it? (using these 2 feature as well in old exclusive) It's not a problem if not, but it would be nice to have them. Thanks!
It's a technical limitation and there's not much I can do about it, without totally rewriting the "old exclusive mode".

I am fairly certain that I went through the new madVR first before wiping the old AMD driver and installing the new one. So I am confident that it was this latest madVR that finally fixed the D3D11 issues I had. With that said, I could do a quick and dirty rollback of madVR to see if this is indeed the case.
It's not really important, I guess, just wondered...

there must be something wrong with how rendertimes are calculated here an example:
http://abload.de/img/rendertimescalculatio6nq9a.png

i mean AVG rendertimes of ~17.5 ms while playing 60 fps without frame drops and MAX rendertimes are lower than AVG...

would a log without SM of any use?
For a bug like this I would probably need a way to reproduce the problem. A debug log wouldn't help much here, because the render times are spread over thousands of lines in the log.

1. the 'restore default settings' .bat file does not seem to actually work properly. i have been trying lots of different builds (very latest is working great!), can't pin down which builds didn't work, but often various settings were just not restored, they stayed exactly how they were.
Can you double check which part of the batch file fails? After running it, is there still a file named "settings.bin" in the madVR folder? If so, delete it manually. This might already solve the problem for the future for you, too. If there's no such file, check whether there's still a registry value named "HKEY_CURRENT_USER\Software\madshi\madVR\Settings", after you've run the batch file.

2. when trying to add keyboard short cuts it won't let me enter 'ctrl' or any combination of ctrl/alt. it just ignores those keys.
You need to manually spell those out. Or maybe I've misunderstood you?

3. it seems when using certain settings other settings just don't do anything? for example DXVA2 mode no NNEDI3 image doubling? maybe it's just me not seeing the difference. If it's true, could it inform the user somehow?

What would really enhance this plugin is to make it more user friendly. For example, there are all sorts of modes for only Vista and Win7. Could it not detect the OS and just choose the best modes in the first place? Also, there is a thread here where someone has described quite well what each option does... making that text appear as a mouse-over popup on each option would be a nice touch.
DXVA scaling might disable NNEDI3, that's correct.

Generally, please understand that madVR is still a work-in-progress. It has not even reached v1.0 yet. As such, the settings dialog is still constantly changing. It's not the right time yet to clean it all up. That will come at a later point in time. For now you'll have to live with some things not being perfectly polished yet...

4. the only real way to see what's going on is to toggle the modes with keyboard shortcuts, is it possible to toggle the NNEDI3 image doubling on and off?
I'll add it to my to do list, but it may be a while before I get to that.

If DVD Navigator is used subtitles are burned by LAV Video Decoder, before it gets to madVR. If DVD Navigator is not used subtitles are rendererd by ISR.
Ok, makes sense. Thanks.