LAV Filters - DirectShow Media Splitter and Decoders

[VictorLS]

Originally Posted by wanezhiling

Because you are using an old LAV build(0.74.1-92) which still supports such H.264 file in hw decoding.
Update your MPC-HC and your lav will lose that ability.

Even next 0.74.1-98 can't DXVA2 HW acceleration of your Girls.Generation.Oh.4in1.201002.HDTV.x264.2160p.120fps.DTSES.6.1ch.mkv but even newest 0.75.0-2 can old NVIDIA CUVID acceleration with about 100 MB more videomemory consumption (so about 700 MB of 1 GB of my GTX750v2 GM206 videocard) than DXVA2 native in 0.74.1-92 but NVIDIA CUVID can't decode all frames while audio stops (DXVA2 native in 0.74.1-92 and also Cyberlink, MainConcept and MPC-BE Video Decoder with DXVA can).

[nevcairiel]

Don't encode your videos out of spec if you want them to work better. If it actually uses 16 ref frames on 4K, then it would artifact decoding in hardware, I didn't add those checks out of nowhere, and this was on modern NVIDIA hardware too.
If it doesn't use all 16 but is flagged to contain 16, then the stream is just bad. As a general rule, 16 ref frames rarely offer a solid advantage, which is why it was reduced on HEVC again to max 8 active ref frames per frame as well.

Artifacts are the worst thing that can happen. I rather not decode some obscure out-of-spec video in hardware then risk artifacts. That has always been my stance on this.

[Sunspark]

Originally Posted by el Filou

Interesting indeed, because IIRC the HEVC decoder in Broadwell was hybrid (used GPU compute and not fixed function unit), so maybe that's where the difference comes from? I would think it's a driver problem but it's hard to know really. Does it give a corrupt image too when using standard EVR ?

No, I checked just now with EVR Custom Presenter, and it displayed fine in DXVA2 Native mode. Thanks for the suggestion to check that.

So based on this, it appears that the bug may be with MadVR after all which hasn't received a public update for a couple years now.

Update: I found a way to make it work in DXVA2 Native mode w/ MadVR for this type of video. If you uncheck "Present frames in advance" it will change it to backbuffers which is D3D9 Old Path. Frames in advance is D3D9 New Path. Not completely sure what the difference between Old and New is, but old works if you want to use Native instead of Copy-Back and even more curious, it very subtly appears to be smoother on panning motion than new.

[VictorLS]

Originally Posted by nevcairiel

Don't encode your videos out of spec if you want them to work better.

Most cases is playing enocoded by someone files (streams, i.e. from SAT) but not own encoded.

Originally Posted by nevcairiel

Artifacts are the worst thing that can happen. I rather not decode some obscure out-of-spec video in hardware then risk artifacts. That has always been my stance on this.

So you still live in ideal world and still don't want to give choice for people as v0lt in their modern MPC-VR with always turning on HLG processing or MPC-BE Video Decoder - just one version has Skip non I-frames (newer has Skip B-frames only isn't enough for 8K in my case)

I use 1.5.3(build4166) only - in case of LAV Video Decoder I'll have to use i.e. 0.74.1-92 in case of playing such Girls.Generation.Oh.4in1.201002.HDTV.x264.2160p.120fps.DTSES.6.1ch.mkv files but I prefer use one (desirable most modern) and most universal video decoder with various settings for all possible cases - if I see artifacts with DXVA2 I prefer just change acceleration to NVIDIA CUVID then install older version of LAV Video Decoder

[nevcairiel]

Originally Posted by VictorLS

So you still live in ideal world and still don't want to give choice for people

Luckily, I don't have to care what you think, and those options will never happen. You are free to not use my software if you don't like my decisions. I don't get anything from it.

[VictorLS]

Originally Posted by nevcairiel

I don't have to care what you think, and those options will never happen.

I guess many people want to have one universal enough good product than many special (but even worse than universal) products for each case.

Originally Posted by nevcairiel

I don't get anything from it.

If you don't want to get 250$ it's your decision
wanezhiling
What about your TigerLake and mpv - it can use HW acceleration (without Video Processing) in cases where LAV Video Decoder and others couldn't?

[wanezhiling]

Originally Posted by VictorLS

wanezhiling
What about your TigerLake and mpv - it can use HW acceleration (without Video Processing) in cases where LAV Video Decoder and others couldn't?

mpv only supports quicksync for av1, too slow.
for hevc vp9 h264, mpv seems a bit faster than mpc-be.

well, i stick with mpc-be

[nevcairiel]

Originally Posted by VictorLS

If you don't want to get 250$ it's your decision

This is an entirely different request, for exposing additional hardware capability and not a cheap performance hack that degrades quality, and will most likely be supported in the re-designed NVDEC backend (which is part of the reason it is infact being replaced, as the old CUVID one has limitations), as I have already responded to before.
But, I also wouldn't do a quick hack to get it working just because someone put some money up. Thats just not my goal with LAV.

[monohouse]

thank 0.75 nice work

[VictorLS]

wanezhiling, nevcairiel
Thanks for your replies

[wanezhiling]

Question about HDR on Intel

Hi nevcairiel, do you have Intel GPUs (7th Kabylake and above)? Can you test whether the image on Intel is different with the one on AMD/NVIDIA when playing any HDR videos(for example) with vanilla EVR. And do you know how does intel process?

ps: If you use wmp12 (microsoft's built-in decoder), the image will be the same as AMD/NVIDIA even on intel.

[nevcairiel]

I do not. But EVR doesnt do any HDR processing, any outcome will be wrong. The difference is likely from obeying the color matrix or not, and the MS decoder just not sending that information. But as said, neither properly reproduces HDR, so its always wrong.

[wanezhiling]

Thanks.
Some developers told me that's intel's problem, but a workaround on decoder side can solve this.
Maybe you can investigate further once you got a iGPU. Anyway, it's up to you.


edit: mpc-be r6170 changed codes for this situation. because Intel automatically tries some transformation when it met hdr videos (VideoTransferMatrix = BT.2020) with evr.

[VictorLS]

wanezhiling
Many thanks - I saw the same color distortion (it looks much worse than without any transformation on my own) with ordinary EVR (so not EVR-CP) - I guess you've called it vanilla EVR - with HDR videos when I tried with Intel's Comet Lake with integrated UHD Graphics 630 and igfx_win10_100.9316.exe driver

[nevcairiel]

Originally Posted by wanezhiling

edit: mpc-be r6170 changed codes for this situation. because Intel automatically tries some transformation when it met hdr videos (VideoTransferMatrix = BT.2020) with evr.

But BT.2020 does not mean HDR, and sending another flag then that one would just be plain wrong. I don't think this issue is understood well enough to make blanket changes that practically make the decoder lie just to make it look wrong in another fashion, so I won't.
It does sound to me like its actually processing BT.2020 (like its supposed to), but you just don't want that for some reason, and thus lie to the renderer.

[wanezhiling]

Originally Posted by nevcairiel

But BT.2020 does not mean HDR, and sending another flag then that one would just be plain wrong. I don't think this issue is understood well enough to make blanket changes that practically make the decoder lie just to make it look wrong in another fashion, so I won't.
It does sound to me like its actually processing BT.2020 (like its supposed to), but you just don't want that for some reason, and thus lie to the renderer.

so the best solution is reporting to intel? let intel change in their driver?

this does affect all bt.2020 videos, indeed. I can't believe no intel users ever found it before? ....

[VictorLS]

Originally Posted by wanezhiling

so the best solution is reporting to intel? let intel change in their driver?

I guess answer on both your questions is Yes
May be you'll ask Intel how to activate their hardware acceleration of H265 4:2:2 and 4:4:4 in Intel Xe (Tiger Lake)?

[*MidnightWatcher*]

Just updated from 0.74.1 to the new 0.75. Unfortunately, all video streams from my FTP server now take around 20 seconds before the videos start playing (local files play immediately). This never happened under 0.74.1 -- they all play immediately. Any idea what setting, if any, I need to change in 0.75, or should I just stick with 0.74.1?

Player: MPC-BE 1.5.6 x64
Renderer: madVR b128

Thanks in advance!

Update: If I only install the LAV Video Decoder 0.75 and keep the splitter and audio decoder at 0.74.1, the videos streamed via FTP play immediately, but if the splitter or audio decoder 0.75 are installed, it takes about 20 seconds before the video begins playing.