madVR - high quality video renderer (GPU assisted)

[madshi]

Originally Posted by aufkrawall

Ah, yes. It seems like a bug in conjunction with upscaling refinement after each 2x upscaling step.

Ok, one more thing to fix.

Originally Posted by huhn

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]

Originally Posted by madshi

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]

Originally Posted by 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...

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]

Originally Posted by CiNcH

settings.bin

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. But I don't think that it will make any difference.

setup.xml

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/ma...sions#download

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

Thanks!!

Originally Posted by XRyche

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?

Originally Posted by huhn

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]

Originally Posted by madshi

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]

Originally Posted by CiNcH

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

Originally Posted by 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

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.

Originally Posted by 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).

Good to hear!

Originally Posted by XRyche

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]

Originally Posted by 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

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]

Originally Posted by CiNcH

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]

Originally Posted by madshi

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]

Originally Posted by XRyche

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]

Originally Posted by madshi

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]

Originally Posted by AndreaMG

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]

Originally Posted by madshi

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