LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

I said 4 posts. Here, have a link to help you out https://forum.doom9.org/showthread.p...40#post1868640
And here, have another link: https://files.1f0.de/lavf/nightly/

[sneaker_ger]

dav1d developers are aware that it uses more memory than necessary.
So 1 more link:
https://code.videolan.org/videolan/dav1d/issues/257

[nevcairiel]

Originally Posted by Pat357

with a 32bit player ?

You should switch to 64-bit, there is no getting around that 32-bit is going to severely limit you eventually, both in performance and available memory.
There is nothing I can do to fix that. As sneaker_ger said, dav1d uses a bit too much memory on 8-bit and/or 4:2:0/4:2:2 samples, but even if that is fixed, it only slightly moves the resource limit, nevermind the significantly slower decoding on 32-bit (since the majority of the AVX2 code is 64-bit only).

When I try decoding such a 4K AV1 stream on my 7900X on 32-bit, all I get is a black screen because it runs out of memory instantly without lowering the thread count. Its not supposed to crash, but I guess there are still some unchecked allocations left somewhere.

Some numbers to further demonstrate how futile 32-bit is. I set LAV to 10 threads on my 10-core CPU, since that seems to allow it to safely run on 32-bit, and benchmarked the full 4K clip you posted

32-bit 10 threads: 63 FPS
64-bit 10 threads: 130 FPS
64-bit auto threads: 145 FPS

So by moving from 32-bit to 64-bit, you can more then double the FPS these files decode at, and thats not going to change much. Even once the memory usage is reduced and you can run more threads on 32-bit, all the fast AVX2 code is going to remain 64-bit only, which will make 64-bit dav1d almost twice as fast on 64-bit if AVX2 is supported.

In any case, whatever reason someone has to stick to 32-bit, it should really be re-evaluated.

[Grimsdyke]

Originally Posted by Grimsdyke

@ nev. Would it maybe an idea to add (basic) profile ability ??
I am asking because on my system I can use DXVA2-copyback on everything up to 1080p but unfortunately I do need D3D11-native for UHD !!

Sorry for 'bumping' this thread but after three months I thought I could ask again because yesterday evening I compared render times watching the Italian "SUSPIRIA"-BD.
D3d11 native: ~ 28.8 msec
DXVA2 copyback: ~ 23.8 msec
I think that is a huge difference and I really could use these 5 msec to further increase performance in MadVR !! I am of course aware that I could always change this every time
depending on the content but I think software should do these tasks for users.
I understand that a profile system might be way too much work but it would be great to have a basic setting so that LAV chooses automatically the decoder !!
Something like:
SD = DXVA2 copyback
HD = DXVA2 copyback
4K = D3D11 native

You could make also it optional so that users with enough GPU horsepower don't even have to bother. Best wishes

[nevcairiel]

I'm sorry, but I don't plan such functionality. D3D11 native should always be the most efficient, note that render times are not really a good measurement, since they depend on the power state of the GPU, which can vary a lot (and if you use a more efficient decoder, maybe it drops down a state)

[lvqcl]

Originally Posted by Pat357

Dam, you're really fast !
As soon as I patched the header from dav1d.exe to -Wl,large_addres_aware, I was able to up the freamethreads to 16. (it used 1900 MB then)
My feeling tells me this is the same problem.

IIRC the support of more than 2GB of RAM is a property of a program, not DLL files that are loaded by the program. And MPC-BE does have LargeAddressAware flag (although I wonder why LAV files don't have it).

[nevcairiel]

LargeAddressAware has absolutely no impact on DLLs, its always controlled by the calling application.

[sneaker_ger]

Originally Posted by nevcairiel

Some numbers to further demonstrate how futile 32-bit is. I set LAV to 10 threads on my 10-core CPU, since that seems to allow it to safely run on 32-bit, and benchmarked the full 4K clip you posted

32-bit 10 threads: 63 FPS
64-bit 10 threads: 130 FPS
64-bit auto threads: 145 FPS

So by moving from 32-bit to 64-bit, you can more then double the FPS these files decode at, and thats not going to change much. Even once the memory usage is reduced and you can run more threads on 32-bit, all the fast AVX2 code is going to remain 64-bit only, which will make 64-bit dav1d almost twice as fast on 64-bit if AVX2 is supported.

For the record: SSSE3 difference seems to be only about 15%.

[DMU]

I can not activate h/w decoding vp9 on AMD Vega GPU in LAV.
Screen 1
In MS Edge all ok.
Screen 2

[NikosD]

Originally Posted by DMU

I can not activate h/w decoding vp9 on AMD Vega GPU in LAV.

Screen 1

In MS Edge all ok.

Screen 2

Edge uses a different mode for HW acceleration than LAV and any other decoder out there.

It's extremely optimized for DXVA using MFT.

For LAV use DXVA2 native NOT dxva copy-back to see the difference.

Still, Edge is even more optimized.

[nevcairiel]

As far as I can tell, Vega doesn't support VP9 through DXVA2. I don't own such hardware, so I cannot test, but there is no hardware specific logic in LAV, so if it doesn't work, then the driver doesn't actually expose that mode.

[el Filou]

Amazing speedup from dav1d in new nightly, on a 6,5 Mbps file I went from 22 to 39 avg fps on my old Core 2 Duo. Still not enough to watch a movie unfortunately, as some scenes where the bitrate goes very high still bring frame drops.
64-bit only brought a 2 fps improvement, I guess because a CPU that old doesn't have the optimized instruction sets that are used.

[nevcairiel]

LAV Filters 0.74

LAV Splitter
- Changed: Using GnuTLS for HTTPS and other TLS protocols, improving performance and compatibility with a lot of web streaming services (ie. YouTube Live Streams through youtube-dl, and more)
- Fixed: Keyframes in MP4 files were being reported with a slightly offset timestamp, resulting in slow keyframe seeking
- Fixed: Subtitles that stretch over chapter boundaries could be lost in Ordered Chapter MKV files
- Fixed: Fonts embedded in MKVs without a proper mimetype were not being imported (now it checks the file extensions for .ttf/.otf as well)

LAV Video
- NEW: Initial support for parsing HDR10+ (SMPTE ST 2094-40) metadata, and passing it to the video renderer
- NEW: Using the dav1d AV1 decoder for significantly improved AV1 decoding performance
- Changed: Re-enabled experimental hardware acceleration for H.264 MVC 3D decoding on Intel GPUs, disabled by default
- Changed: Updated Intel MediaSDK dispatchers to the latest Media SDK, fixing compatibility with newer runtimes in the Intel DCH drivers
- Changed: Improved support for additional UtVideo subtypes

LAV Audio
- Changed: Added an option to disable the PCM fallback when bitstreaming is requested
- Fixed: Further improvements to TrueHD Bitstreaming, resolving glitching on more new titles (particularly seamless branching titles)
- Fixed: Automatic fallback from bitstreaming to PCM could crash in some situations

Download: Installer (both x86/x64) -- Zips: 32-bit & 64-bit

Not much to say that isn't already apparent from the Change Log above. A lot of collected bugfixes, further improvements to TrueHD bitstreaming, which should to the best of my knowledge finally bring it to a fully spec compliant level, dav1d for fast AV1 decoding, and much more.

A quick note on HDR10+ support - without renderer support, this does nothing. Its just additional metadata, and does not impact the decoding of the video. It should feel much like an ordinary HDR10 movie if the metadata is being ignored, and what exactly a renderer does with that metadata is out of my hands.

As always, please report issues, specifically regressions, in as much detail as possible with a sample file if applicable.

Have fun!

[Sebastiii]

Thanks you rocks

[hubblec4]

Thank you for improving Matroska support.

[Manni]

Thanks a lot for your work, much appreciated, as always

[jmone]

Thanks. Quick test on MC25 was all good.

[Carpo]

Hi @nevcairiel

Thanks for the new release, I have a question I wonder if you or others could help me with, I often see people saying use x method over y ( DXVA2(native/copy) over D3D11) so I am never sure which to use, I have two systems

i7-7700K with a Nvidia 1080

and a

i7 4600K with a Nvidia 970

out of all the options, which would you suggest?

Thanks

Edit: I should have added that I have tried both and haven't noticed any difference.

[nevcairiel]

As a general purpose answer when using madVR, DXVA2 Copy-Back is generally the best, since its fully compatible with every feature in all renderers, is fully bit-exact, is reasonably fast (typically faster then D3D11 Copy-Back for complex reasons), and has no feature limitations.

The only reason to use something else is performance, which mostly applies to more low-end systems, where a "Native" mode is required to play 4K 10-bit content, for example, in which case D3D11 Native would be the best option, since it incurs no quality penality. Unfortunately madVR does not support all its features in D3D11 Native mode, so its hard to recommend it as a general option for everyone.

If you use EVR, then DXVA2 Native is usually the best option to use.

Just to mention all modes:
QuickSync or CUVID should generally not be used anylonger, in favor of DXVA2-CopyBack.

[Carpo]

Thanks Nev