4K UHD HDR HEVC 10-bit playback with GT 1030

[prankmunky13 1]

Okay so I guess that's not it. Strange it let me get away with the one liner to implement dxva2 though...

Edited March 20, 2018 by prankmunky13

[Guest asrequested]

I wasn't able to. But at least you have an option, now.

[prankmunky13 1]

Actually both ways worked for me in ET but the 3 liner was the only way to get it to work in the MPV standalone. Anyway, just hope all this testing and benchmarking contributes to the final build! 

Edited March 20, 2018 by prankmunky13

[Guest asrequested]

There are presently 400 commits to the next mpv release. There are some changes to hwdec, So I'm waiting to see where they go, with that.

Edited March 20, 2018 by Doofus

[Guest asrequested]

A little update when using dxinterop

 

https://mpv.io/manual/stable/#options-gpu-context

 

 

if dxinterop doesn't work, you could try

hwdec=dxva2
vo=gpu
gpu-context=angle

Edited March 21, 2018 by Doofus

[prankmunky13 1]

I also spoke too soon... After playing some different 4K HDR content with dxva2 in MPV, I noticed that although the HDR is being mapped in someway (i.e. the picture wasn't totally washed out) it was not being done correctly. Most noticeable was that regions which should be black end up being greyish. This happens when using dxva2 in both ET and the MPV standalone and likely has something to do with this (https://mpv.io/manual/stable/#video): 

 

Quality reduction with hardware decoding

...dxva2 is not safe. It appears to always use BT.601 for forced RGB conversion, but actual behavior depends on the GPU drivers. Some drivers appear to convert to limited range RGB, which gives a faded appearance. In addition to driver-specific behavior, global system settings might affect this additionally. This can give incorrect results even with completely ordinary video sources...

 

I'm guessing this is a primary reason for discontinuing dxva2 support in MPV. However, this issue doesn't happen when using dxva2 native in MPC-BE. So I'm not sure how they get the right RGB conversion and MPV doesn't.

 

 

 

 

[Guest asrequested]

I was wondering if you'd get problems with that. I was aware of that possibility. Try the angle, option. It may yeild better results.

[Luke 37093]

It's possible that it might not be noticeable even when it happens, and mpc is just living with it.

[Guest asrequested]

When I tried MPC-BE, by default it uses EVR enhanced, and it got the colors all wrong. I had to use MadVR to get it right. But with Nvidia GPUs, it may work better. A workaround might be an external player option for HDR. Then mpv can be used externally, for that. I would think the ultimate solution would be to figure out why there's such an increased demand when playing through Theater.

[prankmunky13 1]

Oops forgot to mention that setting the gpu-context to angle just causes no hardware decoder to be used in my case. Seems like those are my only two options according to this:

dxva2: requires --vo=gpu with --gpu-context=angle or --gpu-context=dxinterop(Windows only)

I have since done some more fiddling around with d3d11va in ET because it was the most efficient decoder for me when using the MPV standalone and noticed that it works occasionally in ET too:

 

For example, I played the 1st episode of Blue Planet II and video decode started at 100% as usual but about 10 sec in it just dropped down to 25% which is the normal value I see in the standalone. I played the 2nd and 3rd episode and it stayed down at 25%. When I started the 4th, it immediately shot back up to 100% and didn't come back down. So I went back and tried the 1st, 2nd and 3rd episodes but it just stayed up at 100%. I closed and restarted ET, played the 4th episode again and this time it played smoothly with video decode at 25% but when I switched to another episode it shot back up to 100%. And on and on this goes... Sometimes it happens on the very first 4K HDR I play after opening ET, sometimes I can play a few before it happens. No seeming rhyme or reason! 

 

I checked the GPU breakdown by process and saw that when the issue occurs, the full 100% is coming from the MPV sub-process which is within the electron process. At the same time, all of the electron sub-process show 0% GPU usage. So it doesn't seem that electron itself is contributing to my problems but I guess we cant be sure since MPV is a sub-process within electron. 

 

Finally, by chance I started playing videos in a maximized window (i.e. visible taskbar) instead of full screen mode. Amazingly the 100% video decode problem never occurs when I play them this way. All files start and stay at 25% and I can then maximize them to full screen without issue. Is there anything being done differently behind the scenes when a video is opened in a window vs. full screen?

Edited March 21, 2018 by prankmunky13

[Guest asrequested]

That's curious. All my tests were in a window (to allow me to check the processingl), by I never get any dropped frames.

[Luke 37093]

@ what do you use for mpv conf for hdr content?

[Guest asrequested]

@ what do you use for mpv conf for hdr content?

 

I don't use specificity for HDR. MPV just plays it and applies PQ. But you could use the color matrix

 

https://mpv.io/manual/stable/#video-filters-%3Ccolormatrix%3E

 

Something like this

vf=format=colormatrix=bt.2020-ncl:primaries=bt.2020

Edited March 22, 2018 by Doofus

[Luke 37093]

And that's for display in hdr?

[Guest asrequested]

That will force the colormatrix when playing, to that specific HDR colormatrix. But mpv analyzes and selects the colormatrix, automatically. You'd only want to use that filter if you know that the HDR metadata will match it. Otherwise the colors will be altered. What's the goal you're aiming for?

[Luke 37093]

I just wanted to learn whether it was automatic or not.

[Guest asrequested]

I just wanted to learn whether it was automatic or not.

 

Yes it is, but can be overridden. 

[prankmunky13 1]

Not sure if this helps pinpoint the source of the problem but I have noticed my d3d11 issue with dropped frames caused by the GPU Video Decode getting stuck at 100% when I start or resume a video occurs far less frequently when I run ET in Windows 8 compatibility mode. Does that ring any bells for anyone? Wondering if this a windows or nvidia driver issue now.  But I'm also considering the possibility that my GT 1030 just aint right. 

[prankmunky13 1]

Long live ET 3.0! So long as I run ET in Win 8 in compatibility, everything is perfect. D3D11 efficiently decodes all my material (720p, 1080p, 4K HDR, etc.) and my video decode doesn't get randomly stuck at 100% when starting/resuming any videos. So my issues are more or less solved. Solid work guys.

 

However, when not using compatibility mode I did notice a new issue that you may want to be aware of. Although D3D11 video playback occurs without any dropped frames and appears smooth with 4K content, there is some judder when playing lower resolution content (especially during panning motions). No dropped frames are registered when this occurs, so maybe this has something to do with output and display refresh rates not lining up. Another concerning thing that I also observed is that no matter what I play (720p, 1080p or 4K) my GPU 3D usage goes up to around 95% while the video decode stays down around 15% where it should be. Its almost like the inverse of my previous problem. For comparison, when running ET in Win 8 compatibility mode, my GPU 3D usage is only ~30% and video decode is ~15% for 4K content and lesser for lower resolutions. 

 

Could anyone else with an NVIDIA GPU (preferably GT1030) outputting to a 4K display test out D3D11 hardware decoding and see if they can replicate this? 

Edited March 29, 2018 by prankmunky13