LAV Filters - DirectShow Media Splitter and Decoders

[clsid]

Originally Posted by JarrettH

I'm curious - what would you call a slow cpu? I have a Core 2 Duo E6600 (2.4 ghz) on a GeForce 550 Ti. Of course there are other variables like scaling, but I've found in testing that software decoding is slightly faster than hardware (lower madvr render time in the 0.3 ms range...really nothing). I guess it is machine dependent. 550 Ti is still pretty good

Slow would be when it uses more than 50% CPU for playing a 1080p video. Just for reference, my 5 year old Core i7 uses less than 5%.

[Nullack]

I assume that since nevcairiel is making commits to the ffmpeg GIT, that LAV is pulling from ffmpeg and not the other fork? And that by extension, us users are well protected by Michaels efforts with google on all the fuzz testing security patches that were done.

I notice that GIT for FFMPEG is pretty active each day. Can it be as simple as LAV nightlies pulling down the latest ffmpeg in each nightly build? Or does the LAV filters require some coding and its a bit effort to synch back to ffmpeg regularly?

Many thanks

[nevcairiel]

Updates are done manually to allow me to validate basic functionality and avoid unexpected breakage, since there are a bunch of patches on top of default ffmpeg.

[Nullack]

Understood, and certainly that strategy has been very effective because the nightly builds of LAV have proven to be stable and robust. I guess its better to wait awhile for things like Michael's security patches in ffmpeg to come through in LAV rather than risk a more automated build processes that could disturb the hard won reputation of the nightlies being high quality.

Im not across how effective FATE has been with ffmpeg but maybe into the long term it might be possible to have automated regression tests that would flag automated nightlies as "good" or "regressed" and just published the passed builds. And to have an extent of regression testing through FATE that is comprehensive and reliable to do detailed regression testing say each day with GIT changes that day in ffmpeg.

[Nullack]

Hi, I'm a bit confused. Ive setup my 4K UHD desktop to be YUV 4:2:0 and 12 Bpc with 3840x2160P60hz. Then I said to the latest LAV video nightly build to only output P010 being 4:2:0 in 10 bit using native DXVA 2. When I playback some MAIN 10 HEVC content in the nightly MPC-HC, the ctrl j renderer stats of the EVR-CP says its NV12 for the type and the mixer output. Since I only allowed 10 bit I thought it would be P010 shown in the rederer? thx

[wanezhiling]

EVR-CP can't accept 10-bit

[Aleksoid1978]

EVR-CP can accept P010 if use DXVA decoder, for HEVC MAIN 10 decoder.

[NikosD]

Very interesting new version of NVIDIA Video Codec SDK 6.0, basically for encoding.

It seems that it adds NVCUVID decoding support for Windows 10

NVIDIA Video Codec SDK 6.0 adds following new features.

Unified SDK for video encoding and decoding
Windows 10 official support
Support for H.264 Motion Estimation only mode
Support for input surfaces in RGB format
Support for SEI and VUI fields for H.265
Support for Adaptive Quantization for improved subjective visual quality with H.265 (adaptive quantization for H.264 is already supported)
GPUs supported for H.265 (HEVC) encoding
GeForce GTX 960, GTX 980. GTX Titan X
Quadro M4000, M5000, M6000
Tesla M4, M6, M60
Various quality and performance improvements in encoding
SDK samples no longer require the CUDA toolkit installed in order to build.

https://developer.nvidia.com/nvidia-video-codec-sdk

[nevcairiel]

The CUVID functionality unfortunately didn't change at all in that version, they just combined it in a new SDK. Still fails the same way on Windows 10 as it did before, even their sample decoder throws the same error.
Maybe it needs a newer driver still or something, or maybe its just broke.

[NikosD]

The NVEncC transcoding app which uses the latest Nvidia API version, works fine according to the developer for CUVID decoding under Win 10.

It's the NVEncC v2.00β2 version.

I don't have an Nvidia card to test it, but what exactly is the problem ?

Maybe codec specific, like HEVC ?

Stream compatibility issues ?

Are you using latest drivers and Maxwell card ?

[nevcairiel]

Even their sample application fails the same way, so its not just my code. Basic decoding works, and when you do transcoding maybe thats enough, but it still fails in various other scenarios when used in LAV.
And it fails long before its even told which codec to use, it just can't create the context the way I need it.

[NikosD]

Maybe a sample could help

[nevcairiel]

Like I said, its entirely unrelated to the video being played, it fails to create a cuda context with D3D9 interop, which happens long before it comes in contact with the video.
The sample decoder in the SDK has the same problem.

LAV will then fallback to pure CUVID decoding, however that has a few problems, its not as fast and doesn't have access to the highest quality deinterlacing. And there appears to be a problem that causes decoding to deadlock when OpenCL is being used, eg. in madVR.

[NikosD]

I got an answer from NVEncC's developer that it uses "pure CUVID decoding" which is "stable enough"

Case solved.

[Nullack]

Originally Posted by Aleksoid1978

EVR-CP can accept P010 if use DXVA decoder, for HEVC MAIN 10 decoder.

Thanks, Is this a MPC-BE fork thing only? I tried it in the nightly MPC-HC build x64 using DXVA2 native and a HEVC MAIN 10 L52 stream of 4K footage. The EVR-CP CTRL J stats reported it was all NV12 still, despite me in the LAV filters video decoder telling it to only output P010.

[huhn]

don't forget you are talking about 10 bit input. for output you need FSE.

should work with DXVA2 native and mpc hc too.

[nevcairiel]

I don't think the CTRL-J output changes, since its the data from the EVR presenter, which is not the part that handles the input.
EVR doesn't offer a proper full 10-bit chain, but thats another issue entirely. It can accept P010 DXVA2-Native input on GPUs which support it.

[NikosD]

I did some tests with MS MFT DXVA2 HEVC decoder of Wn 10 build 10586 version using my Intel iGPU (Haswell - hybrid 8 bit decoder) and I saw that MS is a little faster than LAV DXVA2 HEVC but sometimes is a lot faster.

The issue here is that LAV, as I have already written a while ago testing PowerDVD 15 DXVA2 HEVC decoder, doesn't seem capable to utilize fully the GPU all the time for all the clips.

So, there are cases that GPU load drops from 100% to 50% (!) or 60%, stays there a little while and then goes up again and then goes down etc.

On the other hand, PowerDVD 15 DXVA2 HEVC decoder and MS MFT DXVA2 HEVC decoder are almost always at 100% GPU utilization all the time for all the clips.

In order to help you isolate the issue a little more, i think the problem lies somewhere in the GPU "feeding" mechanism.

For the clips that MS DXVA2 HEVC is faster than LAV DXVA2 HEVC, about 20% to 50% (!) I can clearly see that CPU utilization goes that higher too.

It looks like your mechanism of hybrid load balancing between CPU and GPU, keeps always CPU down even for those clips that they need a lot more CPU to feed/help the GPU decoder in order to reach max 100% GPU utilization.

[Aleksoid1978]

Originally Posted by NikosD

I did some tests with MS MFT DXVA2 HEVC decoder of Wn 10 build 10586 version using my Intel iGPU (Haswell - hybrid 8 bit decoder) and I saw that MS is a little faster than LAV DXVA2 HEVC but sometimes is a lot faster.

The issue here is that LAV, as I have already written a while ago testing PowerDVD 15 DXVA2 HEVC decoder, doesn't seem capable to utilize fully the GPU all the time for all the clips.

So, there are cases that GPU load drops from 100% to 50% (!) or 60%, stays there a little while and then goes up again and then goes down etc.

On the other hand, PowerDVD 15 DXVA2 HEVC decoder and MS MFT DXVA2 HEVC decoder are almost always at 100% GPU utilization all the time for all the clips.

In order to help you isolate the issue a little more, i think the problem lies somewhere in the GPU "feeding" mechanism.

For the clips that MS DXVA2 HEVC is faster than LAV DXVA2 HEVC, about 20% to 50% (!) I can clearly see that CPU utilization goes that higher too.

It looks like your mechanism of hybrid load balancing between CPU and GPU, keeps always CPU down even for those clips that they need a lot more CPU to feed/help the GPU decoder in order to reach max 100% GPU utilization.

Maybe you upload test file and you result ?? I compare on Nvidia 960.

[NikosD]

Test file from my test suite:

Fitness-2160p@30fps-8Mbps
http://cloud.ultrahdtv.net/fitness-trailer-8000.mkv

System:
Win 10 x64 Build 10586 - Core i7 4790 - iGPU HD4600@1.5GHz - v4326

DXVA Checker v3.11

Decode benchmark mode:

MS MFT DXVA2 x64 HEVC 75fps CPU 58% GPU ~100%

LAV DXVA2 x64 HEVC 57fps CPU 35% GPU ~70%

I think Nvidia doesn't have this issue.

I would like someone with Intel iGPU to test it.