MPC-HC v2.2.1

[nevcairiel]

The reason for the quality loss is a rather technical one and not necessarily madVR exclusive either.

In DXVA2 there is two basic types of image storage. Surfaces and textures. Video decoding produces surfaces, which are a low-level structure that's basically just a memory buffer.

To process surfaces further, ie. with pixel shaders, or even just show them in screen, you need to convert them into a texture. Unfortunately textures in D3D9 do not support 4:2:0 content that most of our video comes as.

EVR avoids that by using DXVA2 to convert the 4:2:0 NV12 surfaces into RGB, and only then make a texture out of them. But of course you are then at the mercy of the GPU on how it performs the RGB conversion.

So, renderer like madVR try to solve that by copying the NV12 surface to other formats that can have textures, for example by splitting Luma and Chroma. Unfortunately on some GPUs this can incur a slight blur in the Chroma channel. And there we are. As you can guess, any renderer that wants direct access to the untouched NV12 data on a surface might have this problem. I don't know how mpcVR works, but it's possible it still puts it through DXVA RGB conversion like EVR does, which is lower quality then madVR RGB conversion, but avoids this particular problem.

D3D11 on the other hand simply got rid of the difference between surface and texture, and you can freely process the output from the decoder directly.

[NikosD]

Could someone post two frames one with DXVA2 native of EVR and the other by using any other mode in order to see the difference ?

I'm pretty sure that besides the theoritical explanation of the two being different, no visual differences will be shown in a real-world test.

Of course, it is good to know the theory.

[nevcairiel]

DXVA2-Native can have obvious artifacts in madVR in some situations, for example in BT.2020 HDR content, the reduced precision of the Chroma channel can produce obvious banding.
The chroma blur in ordinary content is also visible to some people with good eyes and decent screens, but not everyone is affected the same way.

For EVRs RGB conversion, for "most" content its probably ok-ish, but its quite simply limited to what the GPU supports. If you have unsupported stuff like, for example, YCgCo, you don't have the freedom to fix it.

[DMU]

Originally Posted by NikosD

Could someone post two frames one with DXVA2 native of EVR and the other by using any other mode in order to see the difference ?

dxva2(n)+EVR
d3d11(cb)
Source: Spears.Munsil.UHD.HDR.Benchmark
Video: HEVC 3840x2160 23.976fps [V: hevc main 10 L5.1, yuv420p10le, 3840x2160]

[NikosD]

Originally Posted by DMU

dxva2(n)+EVR
d3d11(cb)
Source: Spears.Munsil.UHD.HDR.Benchmark
Video: HEVC 3840x2160 23.976fps [V: hevc main 10 L5.1, yuv420p10le, 3840x2160]

The difference is huge, never seen that before.

For the first frame of EVR you don't have info like the second.
Are you sure it's not madVR ?

Maybe something is going on with your GPU drivers or the source content (HDR)

[DMU]

Originally Posted by NikosD

For the first frame of EVR you don't have info like the second.
Are you sure it's not madVR ?
(HDR)

100%

Originally Posted by NikosD

Maybe something is going on with your GPU drivers or the source content (HDR)

This is not HDR content

Video
ID                             : 4113 (0x1011)
Menu ID                        : 1 (0x1)
Format                         : HEVC
Format/Info                    : High Efficiency Video Coding
Format profile                 : Main 10@L5.1@High
Codec ID                       : 36
Duration                       : 7 min 45 s
Bit rate                       : 97.3 Mb/s
Width                          : 3 840 pixels
Height                         : 2 160 pixels
Display aspect ratio           : 16:9
Frame rate                     : 23.976 (23976/1000) FPS
Color space                    : YUV
Chroma subsampling             : 4:2:0 (Type 2)
Bit depth                      : 10 bits
Bits/(Pixel*Frame)             : 0.489
Stream size                    : 5.27 GiB (95%)
Writing library                : x265 3.0_RC+11-9a975542fe39:[Windows][GCC 6.3.0][64 bit] 10bit
Encoding settings              : cpuid=1111039 / frame-threads=6 / numa-pools=16,16 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=11158 / level-idc=51 / high-tier=1 / uhd-bd=1 / ref=5 / no-allow-non-conformance / repeat-headers / annexb / aud / hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=1 / keyint=24 / gop-lookahead=0 / bframes=3 / b-adapt=0 / b-pyramid / bframe-bias=0 / rc-lookahead=24 / lookahead-slices=0 / scenecut=40 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=3 / tu-intra-depth=3 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=5 / limit-refs=0 / no-limit-modes / me=3 / subme=4 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / no-deblock / no-sao / no-sao-non-deblock / rd=6 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=95000 / qcomp=0.60 / qpstep=1 / stats-write=0 / stats-read=2 / cplxblur=20.0 / qblur=0.5 / vbv-maxrate=98000 / vbv-bufsize=100000 / vbv-init=0.9 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=14 / colormatrix=9 / chromaloc=1 / chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / qp-adaptation-range=1.00
Color range                    : Limited
Color primaries                : BT.2020
Transfer characteristics       : BT.2020 (10-bit)
Matrix coefficients            : BT.2020 non-constant

[nevcairiel]

The difference in color is quite likely a lack of tone mapping, or EVR is incapable of processing BT.2020 at all.

[huhn]

Originally Posted by NikosD

They mean using DXVA2 native with madVR only not with EVR/EVR-CP or mpcVR, I hope.

no it is a general problem. and has been tested more then once in EVR and madVR. you should know that there are general issues with EVR is going stuff generally wrong making it harder to spot the issues.

the biggest one has AMD right now and with right now i mean years.
10 bit DXVA2 native produces a lot of banding with AMD: https://forum.doom9.org/showpost.php...&postcount=656

nvidia places chroma in the wrong position which can result in aliasing.

AMD broke dinterlancing which is also part of DXVA processing they do this from time to time.

you should know that madVR is used to master movies and is certified by calibration software like calman. it is generally considered to be accurate if the files source information are correct.

[NikosD]

Originally Posted by DMU

Source: Spears.Munsil.UHD.HDR.Benchmark

Video: HEVC 3840x2160 23.976fps [V: hevc main 10 L5.1, yuv420p10le, 3840x2160]

Can you try EVR-CP and mpcVR ?

Thanks!

[DMU]

Of course.
mpcVR wich one?

[v0lt]

MPC Video Renderer
How to use MPC Video Renderer in MPC-HC:
1. Install MPC Video Renderer on the system (run Install_MPCVR_32/64.cmd as administrator).
2. Launch MPC-HC and add the MPC Video Renderer to the external filters.
3. Set the “Prefer” priority for the MPC Video Renderer.

[DMU]

Originally Posted by NikosD

Can you try EVR-CP and mpcVR ?

Thanks!

dxva2(n)+EVR-CP
dxva2(n)+mpcVR

[littleD]

I am on intel here. The way gpu process videos depends on drivers. So the gpu vendor and driver version maters too. I realized recent intel drivers got much better on my win 10 machine. Intel gpu video decoding works smooth as hell with dx11 native finally. Up to 8k, hdr and what not. But dx11 cba and other dxva2 cb works sloow at high resolutions. So cb is always taxing, just maybe one vendor is more influenced that other.

Movie and TV application decode HDR 8k movies flawlessy. But it is using mft dx11 mode. EVR DSH with MPC HC cannot decode HDR properly. It shows no contrast no colour video. To get proper HDR scaling to SDR, i need dxv11. So madvr is working nice with this option on. And MpcVR too, it is smoooth with DX11.

I eagerly wait for adding official support for mpcvr to MPC HC along with subtitles support. Although EVR Custom Presenter was given much attention in the past, its obsolete now because of drivers/system architectural shortcomings. I believe the effort is puting in dx11 ha on win 10 now by MS and other gpu companies ( i mean native support).

[DMU]

@NikosD
Sorry, madVR screenshot was with "this display is already calibrated" (bt709).
Here with disable calibration.

[NikosD]

Originally Posted by DMU

@NikosD
Sorry, madVR screenshot was with "this display is already calibrated" (bt709).
Here with disable calibration.

Then I think this post was right from the beginning

Originally Posted by NikosD

Could someone post two frames one with DXVA2 native of EVR and the other by using any other mode in order to see the difference ?

I'm pretty sure that besides the theoretical explanation of the two being different, no visual differences will be shown in a real-world test.

[nevcairiel]

Originally Posted by NikosD

Then I think this post was right from the beginning

Except, not really. The calibrated picture is how its supposed to look, which you cannot achieve with EVR.

[NikosD]

Originally Posted by nevcairiel

Except, not really. The calibrated picture is how its supposed to look, which you cannot achieve with EVR.

Well, I see all the frames being more or less the same, except one.
The calibrated frame I think is from D3D11VA copy-back, so why it needs calibration ?
Confused.
Let's start from the beginning.
A good test would be the same frame using EVR/EVR-CP/mpcVR/madVR using DXVA native and D3D11VA copy-back without using calibration of any renderer.
If we want to see the original, unconverted frame, any mode besides DXVA2 native and any renderer could provide it.
Probably not using BT.2020 content, if it causes so much trouble.

[aufkrawall]

Why not simply use the better (newer) API?

[nevcairiel]

Originally Posted by NikosD

Well, I see all the frames being more or less the same, except one.
The calibrated frame I think is from D3D11VA copy-back, so why it needs calibration ?
Confused.

The video is BT.2020, the screen is BT.709 (as he had configured it), so you need tone-mapping or the image will look a tad washed out. This is not a feature EVR provides.

As you can see, the first comparison, the madVR image with tone-mapping just has more "pop" to it.

Granted, this feature is independent of the decoding method choosen, but the point is that there is a variety of reasons why EVR is very limited.

[NikosD]

Yes, I think it's time to move on.

From the combination of DXVA2 native + EVR/EVR-CP, we go to D3D11VA native + mpcVR.

And for the purists, there is always madVR.

All the tools are here:
LAV filters/MPC Video,
mpcVR/madVR,
MPC-HC/MPC-BE
and the GPU vendors supporting D3D11VA hardware decoding in their drivers/HW.

Our main focus should be to the newest member of this family of tools, mpcVR, to be optimized, bug free and integrated as much as it can be to MPC-HC or any other of our favorite DirectShow players.

That's all folks!