LAV Filters - DirectShow Media Splitter and Decoders

[madshi]

I'm not sure if that's my problem or LAV's problem? Could be that my D3D11 pixel shader is somehow not compatible with DX9 GPUs. Or could be that the D3D11 device created by LAV needs to be created with different flags? I don't know. nevcairiel, what do you think?

[nevcairiel]

No idea without any hardware at hand. I can go dig in my GPU bin to see if i still have something that old but yet still with decoding support.
Check with EVR if copy-back works, as one intermediate step? That'll tell you if decoding works.

The best, er.., worst, I can do is apparently a GTX 260-216, which is a DX10 GPU. Will test that tomorrow.

[Great Dragon]

Hello,

Is it OK that using NVIDIA CUVID decoder makes GPU to run on maximum performance (clock speed)?
While using regular DXVA renderer a GPU performs in regular Desktop Mode. I'm using GTX 1070.

Do I have some control over CUVID Renderer settings?
And what's the difference between CUVID and DXVA ?

[strumf666]

D3D11 native on intel HD2500 (I5 3470) works for me if that helps. Win 10 pro & Potplayer 64bit; intel drivers 10.18.10.4425
On a very quick test for H264, cpu utilization is a few % lower than on dxva2 copyback, but render times are much higher.

[aufkrawall]

Originally Posted by Great Dragon

Is it OK that using NVIDIA CUVID decoder makes GPU to run on maximum performance (clock speed)?

That's normal for all CUDA apps, CUVID unfortunately isn't an exception.
DXVA2/D3D11VA on the other hand will give you lower GPU clocks than even CPU decoding with madVR because the driver apparently chooses lower clock speeds when hardware decoding is going on than without.

I don't really see any reason to use CUVID anymore. imho both CUVID and QuickSync probably could even get removed out of LAV Filters in favor of the new D3D11VA decoding.
It's probably not too harsh when you say that CUVID and the used QuickSync decoder are end of life or even already dead.

[aufkrawall]

With new build, I can confirm that selecting IGP for decoding works with D3D11VA, great.
Buuut: Would it be possible to make copyback selectable like for DXVA2? Or do that automatically when a device is selected which is not the primary graphics adapter?
Kinda odd that it currently only works with renderers which refuse direct D3D11VA connection.

[AngelGraves13]

VC-1 playback doesn't work for me with DX11 LAV Video (0.70.2-45 nightly) and madvr 0.92.1b. Can someone else confirm this on their end? My GPU is a 1080 Ti. DXVA2 N and CB work fine. Also, software works fine too, as well as CUDA.

[nevcairiel]

Originally Posted by aufkrawall

Would it be possible to make copyback selectable like for DXVA2? Or do that automatically when a device is selected which is not the primary graphics adapter?

I didn't want a seperate entry in the decoder box because that doesn't allow seamless fallback between Native and Copy-Back.

However I have changed it now to only use Native when you select "Automatic" and updated the instruction hint to that effect. It probably makes the most sense to always obey user settings, and for testing purposes its probably a good thing as well.

Originally Posted by AngelGraves13

VC-1 playback doesn't work for me with DX11 LAV Video (0.70.2-45 nightly) and madvr 0.92.1b. Can someone else confirm this on their end? My GPU is a 1080 Ti. DXVA2 N and CB work fine. Also, software works fine too, as well as CUDA.

VC-1 works just fine here. Make sure you don't use way too many buffers (ie. input queue size in madVR), it can sometimes cause decoding failures.

I should probably put an artificial limit in place for VC-1, it seems to be more affected by this then the others, but I would generally not recommend to use extremely large decoder queues in madVR either way.

[aufkrawall]

I think with native hardware decoding, it's safe to stick to a queue which is as short as possible on the GPU side (aka 4 frames with madVR).
With a short GPU/presentation queue, there are sometimes presentation glitches reported after the playback started, but I haven't yet seen any at a later time. + it also reduces input lag when e.g. changing volume via mouse wheel.
However, setting CPU queue (isn't it actually a D3D11VA queue in our case?) to only 4 frames as well gives me some weird intensive stuttering which is not detected by madVR's stats. It already seems to be gone with 5 frames, but for safety I set it to 8.

Only 12 more hours till next nightly build.

[nevcairiel]

4 is probably too short, especially because it also limits the GPU queues then, I would go with 8 or 16 at most personally.

I've been thinking about more strictly limiting the maximum number of surfaces in all cases to something reasonable like 32 (which is used for VC-1 now). There is a hard limit of 127 (ie. 7-bit), which is required for DXVA to function at all, but using that many buffers really has no advantages in native mode.

[AngelGraves13]

Originally Posted by nevcairiel

VC-1 works just fine here. Make sure you don't use way too many buffers (ie. input queue size in madVR), it can sometimes cause decoding failures.

I should probably put an artificial limit in place for VC-1, it seems to be more affected by this then the others, but I would generally not recommend to use extremely large decoder queues in madVR either way.

I have them both maxed in madvr. 24 for GPU and 128 for CPU. It looks better for smooth motion, but a limit should be put in place if it's a problem in DX11. Why does it work fine in every other mode with large queues except DX11? Is it a bug? Software, CUVID, DXVA2 Native and Copy-Back all work fine with 128 queue.

I also get random freezes if I pause and attempt to play a video with DX11, especially if I skip to a certain timecode and then pause. The player MPCH-HC locks up under DX11, but DXVA2 Native and Copy-Back have no issues.

[nevcairiel]

The CPU queue doesn't affect anything with smooth motion. Don't buy into snake oil explanations.
Such a huge CPU queue has zero benefit, just eats up your memory and makes seeking/startup slower.

[el Filou]

I watch a lot of DVB, and sometimes there are errors in the feed due to bad reception and I find that when this happens, having a bigger decoding queue smoothes things out a bit (i.e. the hiccup due to lost packets is less brutal), but nothing quite as big as 128 (I use 24).

[aufkrawall]

It works like a charm now, nev. Very cool tech, thanks for making it possible!
I thought my Skylake IGP wouldn't be able to decode HEVC 10 bit, but apparently it is (with high GPU usage, so likely hybrid).

[Goeggel]

No hardware acceleration with 4K videos

I have been looking around the web for possible solutions and have fiddled with the settings, but haven't had any luck so far. When playing 1080p videos, I get hardware acceleration and LAV shows my GTX 980 as active hardware device.

However when playing 4K videos (for example Exodus or Life of Pi HDR demos), no active hardware device is shown. Is this a known issue?

Windows 7 64bit
Nvidia GTX 980 384.94
LAV 0.70.2 / DXVA Copy-Back
madVR 0.92.1
Zoom Player 13.5 Max

[LigH]

Not every graphic chipset supports hardware accelerated decoding for every video format (AVC/HEVC, Profile@Level + several specific encoding complexity attributes) in every resolution. There are limits.

[nevcairiel]

The 980 doesn't have full HEVC decoding, and no HEVC 10-bit at all, which would be required for those HDR demos. Like LigH said, older hardware doesn't support all newer formats.

[huhn]

Originally Posted by huhn

is d3d11 headless mode also planned for the next release?

so i take the nightly 0.70.2.49 as a yes.
fantastic feature very useful!

[aufkrawall]

One more observation regarding queue length + madVR:
DXVA deinterlacing really doesn't like a small GPU queue. When I set it to 4 and presentation queue is 4 frames as well, I'm getting framedrops. Setting GPU queue to 8 seems to be enough to avoid drops with DXVA interlacing.

[nevcairiel]

Yeah 4 might be too short, but 8 is fine, or even 16 if you must, with an absolute maximum of 32. Anything above that seems wasted.