madVR - high quality video renderer (GPU assisted)

[Ecmslee]

I'm wondering if anyone else is experiencing this bug when playing HDR video with 3dluts enabled. I haven't seen it mentioned in the thread or the bug tracker, so here it is:

HDR content appears washed out when 3dlut is enabled. It looks just like when using EVR. The problem goes away when I disable the 3dlut.

The bug still exists after the following troubleshooting steps were taken:
-restored default madVR settings
-used Intel igpu instead of Geforce
-tried a different system

SDR content looks fine with 3dluts enabled. The 3dluts were created with ArgyllCMS 1.8.3 and dispcalGui. The bug exists in madVR v0.89.18 up to the current v0.90.1. I am testing this issue with the HDR Life of Pi and Exodus clips. Ctrl+J reports both videos as HDR.

I tried working around this bug by using profile groups to disable 3dluts when playing HDR content. However it turns out that both the profile rules page and the HDR boolean also have issues.

After creating a calibration profile group for my display, each keystroke in the rules text entry box causes me to jump back to "color & gamma". This made for an annoying time of having to type my rules one character at a time and clicking back to the profile group page after each key. So instead I wrote my rules in a text editor and copy-pasted the following back to madVR settings:

if (HDR) "HDR"
else "SDR"

HDR profile has 3dluts disabled and SDR has them enabled. The problem here is that madVR is selecting SDR profile for both HDR and SDR content. If I use

if (! HDR) "HDR"
else "SDR"

then I get the opposite where madVR is selecting HDR profile for every video.

[madshi]

Originally Posted by iakoboss7

here you are, i tested your latest release also and it still had the same problem (but the debug is from v0.90.0 ).

https://drive.google.com/file/d/0Bz9...ew?usp=sharing

Thanks, will have a look at it later.

Originally Posted by x7007

EDIT : (Scratch That) Checking something else ))) in windows 8.1 I have Present Queue drop every couple seconds, it drops from 2-3/3 to 0 or 1-3/3 . I just upgrade since the version 89.x lastest one. it worked fine with the version before 90.

It happens in FSE and windowed. D3D11

Can you create a debug log for this, please?

Originally Posted by MistahBonzai

Update: 1/11/2016
Completely uninstalled madVR v0.90.1 (ran uninstall.bat, reset settings, deleted folder...) and installed madVR v0.89.19. With MPC-HC 1.7.10.56 (nightly) the issue is resolved. Updated to madVR v0.90.1 and the issue is back - MPC-BE works as expected in both cases. Downgraded to madVR v0.89.19 (copied new files over old ones after running uninstall.bat) and all is well. I'm stumped

To make sure I got it right: The issue is that changing settings isn't visible on screen until you unpause the video, correct? Can you please create a debug log for me by doing this:

1) Pause the video.
2) Wait 20 seconds doing nothing (so that I know where to look in the debug log).
3) Change a setting so that madVR *should* change the image but doesn't.
4) Close the media player immediately.

Thanks.

Originally Posted by Q-the-STORM

Just to clarify, does that mean that on win8+ you don't need 3DTV Play for nvidia GPUs anymore?

I don't think I have it installed and 3D playback works just fine for me.

Originally Posted by x7007

I've found an issue with madvr 90.1 . With potplayer if you minimize the window and open it, the video freeze but the sound continues . to start the video again you need to enter FSE.

That's probably the same issue some other users have already reported.

Originally Posted by Nullack

I managed to crash madvr v 0.90.1. Pastebin of the error dump is here:

http://pastebin.com/fqKG6L3a

I was just doing some regression tests with nvidias stereoscopic 3d mode enabled in trying to get the situation down pat for my nvidia bug report. Most of the time I dont get madvr crash reports where MPC-BE crashes instead, but this time it did happen.

Yeah, the crash is in nvwgf2umx.dll, which is an NVidia driver DLL. This information might be useful if you could include it in bug report to NVidia. It's most probably always this DLL that crashes.

Originally Posted by jmone

I've not got 3D working in JRiver MC either yet.

On the crash, when I "reset" the MadVR settings it sovled the crash, I then started re-enabling stuff and for me it is the D3D11 mode that seems to cause the crash.

I'm also nVidia (660Ti) Windows 10 64-Bit

This suggests that 3D decoding isn't properly setup/working for you yet.

Originally Posted by Schwartz

The strange freeze bug happened again. Some more info. MPC-HC froze up almost completely, with a slice of audio being played every 4 or 5 seconds. Ctrl-J did not do anything. Pause-Resume fixed the audio only. Audio started playing again but video continues to be frozen.

The log is here: http://pastebin.com/LAUrQ3Eg

Thanks, will have a look when I find some time.

Originally Posted by Aleksoid1978

nevcairiel, madshi - I found the reason that 3D is not working, LAV Video can't load libmfxsw32.dll/libmfxsw64.dll from installed path (C:\Program Files (x86)\LAV Filters). CDecMSDKMVC::Init() output CDevMSDKMVC::Init(): MSDK not available and out with error.

When i copy this .dll to C:\Windows - all working, thanks

Oh, good find!

Originally Posted by SamuriHL

Well, I'm not having a lot of success so far. I originally tried to get this to work in MC21 and when I enable 3D in the nVidia control panel or in Windows Display settings and try to play a 3D MKV, it crashes the player. So I figured I'd simplify my life while testing and get MPC-HC set up and I'm having the exact same problem. Crashing culprit is c:\windows\system32\nvwgf2um.dll which presumes it's dying in nVidia land somewhere.

This suggests that LAV isn't outputting 3D to madVR yet. Can you double check the LAV settings page? Which "active decoder" is listed there?

Please note that the MKV needs to be a remux of a true 3D MVC Blu-Ray. A side-by-side MKV won't do, it's not considered 3D by either LAV or madVR.

Originally Posted by jmone

Copying the DLL into the Windows folder "almost" works for me.

Now I can see my TV do the Black Screen with change of Refresh rate thing but oddly it seem to happen a couple of time (and the TV complains about losing the HDMI connection in the middle). When the image comes up madVR is using D3D9 not D3D11 and I get a Side By Side image.

Strange. Do you have display mode / refresh rate changing active in either madVR or MC? If so, try disabling that to see if that helps. Also try with MPC-HC to make sure it's not media player specific.

Originally Posted by huhn

are you sure you used a MakeMKV MKV remux for this test?

these files are not played as side by side.

madVR does convert such MakeMKV MKV 3D remuxes to side-by-side if the OS 3D support is disabled, or if you're on Windows 7 or older, or if the display or GPU doesn't support frame packed 3D.

Originally Posted by Balthazar2k4

Does anyone have smooth 3D playback on a Haswell or later NUC? My 2D content works great on it, but 3D is very jerky. The processor is showing minimum utilization so I am wondering if the GPU is maxed out with 3D content.

GPU needs twice the power for 3D rendering. So you may have to reduce GPU load a bit by adjusting your madVR settings.

Originally Posted by 4h4h270

problem sovled!, I just set madvr disable 3d when playback 3d,then the picture become SBS, I just need to choose SBS 3D in my monitor, works perfect!

Does your display not support frame packed 3D, though? SBS works ok, but it means you have to manually enable SBS in your monitor, which is not very comfortable. Furthermore resolution will be half of what it should be. So having frame packed 3D output would definitely be the better solution.

Originally Posted by Ecmslee

I'm wondering if anyone else is experiencing this bug when playing HDR video with 3dluts enabled. I haven't seen it mentioned in the thread or the bug tracker, so here it is:

HDR content appears washed out when 3dlut is enabled. It looks just like when using EVR. The problem goes away when I disable the 3dlut.

Do you have a 3dlut for BT.2020? I have an extra "hack" in place for BT.2020 3dluts which disabled my own HDR processing if a BT.2020 3dlut is active. The reason for this is that some professional users have been doing HDR processing with a BT.2020 3dlut, by baking HDR tone+gamut mapping into the 3dlut. I will probably disable this hack soon, allowing you to use a BT.2020 3dlut for HDR, too.

For now, please simply leave the BT.2020 3dlut slot empty. All the current HDR content (like Life of Pi or Exodus) are really only DCI-P3, anyway. So provide a P3 3dlut, leave the BT.2020 3dlut empty, and you should be set.

[MistahBonzai]

Originally Posted by madshi

Thanks, will have a look at it later.


Can you create a debug log for this, please?


To make sure I got it right: The issue is that changing settings isn't visible on screen until you unpause the video, correct? Can you please create a debug log for me by doing this:

1) Pause the video.
2) Wait 20 seconds doing nothing (so that I know where to look in the debug log).
3) Change a setting so that madVR *should* change the image but doesn't.
4) Close the media player immediately.

Thanks.

I'm feeling kinda incompetent about now but..how do I force a debug log?

[madshi]

Originally Posted by Ecmslee

After creating a calibration profile group for my display, each keystroke in the rules text entry box causes me to jump back to "color & gamma".

I can reproduce this, but only if your display is not set to a clear device type (still has a question mark symbol). Tell madVR which kind of display device it is, and this problem should be gone.

Originally Posted by Ecmslee

The problem here is that madVR is selecting SDR profile for both HDR and SDR content.

Double checked, and it's working fine for me!

Originally Posted by MistahBonzai

I'm feeling kinda incompetent about now but..how do I force a debug log?

Double click "activate debug mode.bat". Then run the video and reproduce the problem. Then close the media player. Now there should be a debug log on your desktop. If that doesn't work, check my last couple of posts, in one of them I explained how to activate the debug mode in case the batch file doesn't work.

[huhn]

Originally Posted by MistahBonzai

I'm feeling kinda incompetent about now but..how do I force a debug log?

go to the madVR folder and run "activate debug mode.bat".

the debuglog will be on your desktop and don't forget to compress it before upoading.

[nevcairiel]

Originally Posted by Aleksoid1978

nevcairiel, madshi - I found the reason that 3D is not working, LAV Video can't load libmfxsw32.dll/libmfxsw64.dll from installed path (C:\Program Files (x86)\LAV Filters). CDecMSDKMVC::Init() output CDevMSDKMVC::Init(): MSDK not available and out with error.

When i copy this .dll to C:\Windows - all working, thanks

Are you loading LAV in some strange way? By default loading a DLL from the module directory should work fine.

Edit:
I updated the DLL loading in the dispatcher and hopefully it should always pick it up from the LAV directory now.

[omarank]

Originally Posted by madshi

SBS works ok, but it means you have to manually enable SBS in your monitor, which is not very comfortable. Furthermore resolution will be half of what it should be. So having frame packed 3D output would definitely be the better solution.

I was wondering if madVR could also process SBS and TBB videos to extract the video frames, stretch them in their proper aspect ratio and then output the stereo frames as frame packed 3D if 3D is enabled. If 3D is not enabled then only one frame of the two can be displayed.

This will not only ensure higher quality output for 3D, but also those who don’t like/ have 3D display can watch the SBS & TBB content in 2D.

[chros]

Originally Posted by chros

Probably you remember that I had/have huge performance difference using D3D9 FSE Old Path on my laptop. I managed to screw up things in the last 2-3 weeks and it works only with 32bit player (luckily found out) and filters now but not with x64 chain!!!
So maybe this is the perfect occasion to figure it out what is going on since I can replicate both now.

What I did in the past 2-3 weeks (I wanted to try out 4:4:4 output on my system but I didn't manage to do it ):
- uninstalling/installing intel graphic driver and Management Engine as well (it responsible for HDMI handshake if I understand it correctly)
- upgrading nvidia driver to 361.xx
- updating players, filters
Now I tried to "revert" everything to the state that it was before., you can see it in my signature.

What I tried is using different versions of MPC-HC , madvr , lavfilters (external) but nothing helped.

I have created logs with madvr, but all I can see it in them that it using the igsimsum*.dll -s successfully. I checked them in:
- c:\windows\system32 and c:\windows\system32\NV
- c:\windows\wow*\ and c:\windows\wow*\NV (I forgot the full path for that)
but the correct version are there for both 32 and 64 bit.

So, how the heck can I debug it what's the bottleneck?

MadVR x32 and x64 logs (~ 20 sec playback): http://www1.zippyshare.com/v/YdKiA4Zc/file.html

This is the stat of nvidia inspector (GPU-Z provides the same results) http://www.imagebam.com/image/6c7fde458360826
Rows are from top to bottom: GPU usage, VPU usage, memory, GPU Clock, memory clock, sahders (zero all the time), GPU voltage. x64 chain is on the left and x32 is on the right.

Thanks

Originally Posted by madshi

I don't remember any details. I'm not sure I fully understand your post. Are you saying you have the problem only in 32bit now but not in 64bit? Or are you saying that 64bit doesn't work at all, anymore, now? I'm not really sure. In any case, an Optimus laptop behaving strangely is not really new. If you find a way to make it work well enough for you, then maybe it doesn't make too much sense spending hours on trying to figure out why it sometimes behaves strangely?

Sorry if it wasn't straightforward. I'm telling that it's only working fine now with 32 bit and not with 64 bit chain.
It's definitely not madvr's fault. But I'd like to get help from You (since it's so specific) about how I can debug it? e.g. link for tutorials/tools that I have to use to able to determine what can produce this bottleneck when using 64 bit or what is going on when I'm using 32 bit (what dlls, etc.). I've posted the logs that maybe you can see something out of ordinary in them (but I doubt it).
Thanks

[Ecmslee]

Originally Posted by madshi

For now, please simply leave the BT.2020 3dlut slot empty. All the current HDR content (like Life of Pi or Exodus) are really only DCI-P3, anyway. So provide a P3 3dlut, leave the BT.2020 3dlut empty, and you should be set.

Yes, I created 3dluts for each specific gamut. Clearing the BT.2020 LUT fixes the problem with HDR and 3dlut, thanks!

Originally Posted by madshi

I can reproduce this, but only if your display is not set to a clear device type (still has a question mark symbol). Tell madVR which kind of display device it is, and this problem should be gone.

This problem happened with my PG278Q set to Digital Monitor / TV. I did not think to try it before I had already set the device type. Also I noticed that it jumps to a different page with every text box in the profile group, not just the rules: group name, profile name, command line to execute, etc.

Setting the device type to Receiver, Digital Monitor, CRT monitor causes the jump upon text entry. The jumping does not occur when I set it to Digital or CRT projector.

Originally Posted by madshi

Double checked, and it's working fine for me!

Not sure what's going on here. 3dlut on/off is no longer an issue now that I've disabled BT.2020, but the boolean is still flagging HDR content as not HDR on my end. BTW I am using LAV Filters 0.67.0. I'll try the nightly and see if that changes anything.

UPDATED:
The LAV Filters nightly fixed the boolean issue. HDR content is correctly detected in the profile rules after I installed LAV Filters 0.67.0-54.

[Xaurus]

Hello folks, I have a problem with my setup. I have a Samsung 65HU8505 with the SEK-3500 upgrade box.
I can successfully run 4K @ 60Hz @ 4:4:4, at least that is what it shows with this image when I load it into mpc-hc in windowed mode.
Also it is what it says when I view the image in a browser.

When I enter fullscreen mode (FSE, overlay, non-FSE etc) it changes to 4:2:2.
I suspect it is because madvr resizes the image. If I view it in the browser at non-original resolution (ie zoom) the 4:4:4 disappears.

Is this normal/expected behavior? This is with the latest 90.1 madvr. Tried disabling Aero etc but same thing. (Win 7)

Thanks.

[madshi]

Originally Posted by nevcairiel

Are you loading LAV in some strange way? By default loading a DLL from the module directory should work fine.

Could it be some sort of NTFS rights problem? Maybe the DLL file ends up having weird NTFS attributes due to being downloaded? Just a wild guess, though.

@Aleksoid1978, can you double check the NTFS access rights of the Intel DLL? Does it work if you remove it again from the system folder, and add "READ" and "EXECUTE" NTFS rights to this DLL for "Everyone"?

Originally Posted by omarank

I was wondering if madVR could also process SBS and TBB videos to extract the video frames, stretch them in their proper aspect ratio and then output the stereo frames as frame packed 3D if 3D is enabled. If 3D is not enabled then only one frame of the two can be displayed.

This will not only ensure higher quality output for 3D, but also those who don’t like/ have 3D display can watch the SBS & TBB content in 2D.

Yes, I was already expecting this request... I might add it in a future build.

Originally Posted by chros

Sorry if it wasn't straightforward. I'm telling that it's only working fine now with 32 bit and not with 64 bit chain.
It's definitely not madvr's fault. But I'd like to get help from You (since it's so specific) about how I can debug it? e.g. link for tutorials/tools that I have to use to able to determine what can produce this bottleneck when using 64 bit or what is going on when I'm using 32 bit (what dlls, etc.). I've posted the logs that maybe you can see something out of ordinary in them (but I doubt it).

Unfortunately I don't really have any good ideas how to debug this at the moment.

Originally Posted by Ecmslee

This problem happened with my PG278Q set to Digital Monitor / TV. I did not think to try it before I had already set the device type. Also I noticed that it jumps to a different page with every text box in the profile group, not just the rules: group name, profile name, command line to execute, etc.

Setting the device type to Receiver, Digital Monitor, CRT monitor causes the jump upon text entry. The jumping does not occur when I set it to Digital or CRT projector.

Strange, I'll see if I can find a way to reproduce that.

Originally Posted by Ecmslee

Not sure what's going on here. 3dlut on/off is no longer an issue now that I've disabled BT.2020, but the boolean is still flagging HDR content as not HDR on my end. BTW I am using LAV Filters 0.67.0. I'll try the nightly and see if that changes anything.

Does madVR detect that it's HDR? If so, the LAV build probably shouldn't matter for the "HDR" profile variable. But it would still be worth a try using a nightly LAV build. If for nothing else, it should feed madVR with proper HDR SMPTE 2086 metadata, which will help image quality. I think the current official LAV build doesn't do that yet.

[huhn]

the image only works when not scaled at all.

the 4:4:4 alone is not worth that much anymore . if the TV is oversharing than the 4:4:4 could be visible too.
if you want to confirm your TV isn't subsampling look at the pixel around the 4:4:4 and look if you can see the blue and pink pixel next to each other.

[madshi]

Originally Posted by Ecmslee

UPDATED:
The LAV Filters nightly fixed the boolean issue. HDR content is correctly detected in the profile rules after I installed LAV Filters 0.67.0-54.

Oh. I might consider this a bug then. The "HDR" profile variable should not depend on getting metadata info from LAV. But good to hear it's fixed for you.

Originally Posted by Xaurus

When I enter fullscreen mode (FSE, overlay, non-FSE etc) it changes to 4:2:2.
I suspect it is because madvr resizes the image. If I view it in the browser at non-original resolution (ie zoom) the 4:4:4 disappears.

Is this normal/expected behavior?

Which media player are you using? If MPC-HC/BE, try setting the zoom to "Normal size". Does the 4:4:4 still disappear?

[nevcairiel]

Originally Posted by madshi

Could it be some sort of NTFS rights problem? Maybe the DLL file ends up having weird NTFS attributes due to being downloaded? Just a wild guess, though.

@Aleksoid1978, can you double check the NTFS access rights of the Intel DLL? Does it work if you remove it again from the system folder, and add "READ" and "EXECUTE" NTFS rights to this DLL for "Everyone"?

Its not exactly downloaded, a 7z file is downloaded and the DLL unpacked from that one.
I changed the load logic to always look in the LAV directory specifically, hopefully that helps those were it failed. Previously I trusted the mfx dispatcher to find it, which seemed to work just fine for me.

[madshi]

Originally Posted by nevcairiel

Its not exactly downloaded, a 7z file is downloaded and the DLL unpacked from that one.
I changed the load logic to always look in the LAV directory specifically, hopefully that helps those were it failed.

Hmmmm... Yes. After thinking about it, you're right, the path is probably the issue and your change should fix the problem. Calling LoadLibrary will search in the "GetCurrentDirectory" (which is unlikely to point to LAV's directory) and it will probably also search in the folder where the EXE file is located. But it will *not* search in every folder of every loaded DLL, and LAV is just one out of many DLLs loaded in the media player's process, from the OS' point of view. So it makes sense that the OS isn't able to find the DLL.

[Xaurus]

Originally Posted by huhn

the image only works when not scaled at all.

the 4:4:4 alone is not worth that much anymore . if the TV is oversharing than the 4:4:4 could be visible too.
if you want to confirm your TV isn't subsampling look at the pixel around the 4:4:4 and look if you can see the blue and pink pixel next to each other.

Thanks a lot, that's what I suspected.

[madshi]

Note to all 3D users: It seems that madVR can crash when you're trying to do 3D playback with D3D9. Please manually activate D3D11 mode to make sure that doesn't happen. (This only applies to 3D playback.)

[Aleksoid1978]

madshi
I can run 3D MKV, But i only get this picture:


I think it's wrong. madVR settings is default. Try to change from D3D9 to D3D11 - don't help. I think it's happened because of my TV model(in signature).

[Neroldy]

@madshi
I found that there might be a freeze bug in madVR 0.90.0 and 0.90.1.
I play a video in MPC-HC and minimum the player and do other things, and then back to player, but found the video is stop but the audio is still playing. I roll back to madVR 0.89.19 and everything is fine. Test mp4, mkv, ts file and all failed.
MPC-HC (Nightly, 64-bit)
------------------------

Build information:
Version: 1.7.10.56 (c8ef218)
Compiler: MSVC 2015 Update 1
Build date: Jan 9 2016 01:12:23

LAV Filters:
LAV Splitter: 0.67.0.54
LAV Video: 0.67.0.54
LAV Audio: 0.67.0.54
FFmpeg compiler: MinGW-w64 GCC 5.3.0

Operating system:
Name: Windows NT 10.0 (build 10586)
Version: 10.0 (64-bit)

Hardware:
CPU: AMD A10-5750M APU with Radeon(tm) HD Graphics
GPU: AMD Radeon HD 8650G + HD 8790M Dual Graphics (driver version: 8.17.10.1404)
madVR log file uploaded.
Attachment 15213

Attachment 15214

Attachment 15215

Attachment 15216

Attachment 15217

[Aleksoid1978]

That's type of 3D display i select in PowerDVD for 3D is working: