View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
clsid
27th November 2015, 16:08
How come when I use AviSynth (Limited Sharpen Faster, LSF) as a real time post processor (via ffdshow raw) in Zoom Player, DXVA2 Native falls back to software decoding (avcodec).In case of DXVA2 native, the decoder must be connected directly to the video renderer. If you put something in between, it won't work, and it falls back to software decoding.
nevcairiel
27th November 2015, 16:58
Future versions of LAV may show some info in the properties which GPU is being used for decoding, when the new page for HWAccel config/info arrives.
Digiface
27th November 2015, 17:45
the hardware has little to do with this. the number of major issues in new driver is rising and rising.
341.81 aren't new driver.
and what do you gain from CUVID?
What's good alternative for CUVID? Or should i use HW-decoding at all? I have just thought that HW-decoding is a good thing.
clsid
27th November 2015, 18:15
What's good alternative for CUVID? Or should i use HW-decoding at all? I have just thought that HW-decoding is a good thing.DXVA2 copyback is a good/better alternative.
If you have a fast CPU, then software decoding is the best choice imho. It is simply more reliable than hardware acceleration. Quality is the same.
Future versions of LAV may show some info in the properties which GPU is being used for decoding, when the new page for HWAccel config/info arrives.Will the HWA info be on a generic status page? Along with other details like framerate, video format (and level/profile when applicable), input/output colorspace, resolution, and interlacing info?
Some basic details in the mouseover of the systray icons would also be nice. Perhaps something for on the long term todo list.
Digiface
27th November 2015, 19:13
DXVA2 copyback is a good/better alternative.
If you have a fast CPU, then software decoding is the best choice imho. It is simply more reliable than hardware acceleration. Quality is the same.
Ok. I switched to copyback and it seems good. My CPU is quite old and cpu usage is lower with DXVA, so i will use it for both HD and SD.
ikarad
27th November 2015, 21:28
What means this new option? How use it?
I have a 5.1 with surround speakers in the back and not the side. What are the differences in sound?
If anybody can explan me, thanks very much.
foxyshadis
27th November 2015, 23:51
CUVID wasn't always a bad thing; it used to be that you got some sharpening and other post-processing for free when you used it, but now that it's been de-prioritized by Nvidia, you have to switch to MadVR or MPDN, or use a shader in MPC, for GPU post-processing instead.
salam2009
28th November 2015, 05:19
Hey guys,
My m2ts files Audio are decoded by Microsoft DTV-DVD Decoder instead of external LAV filters. (and yes, they're preferred and video decoder is working fine)
So I disabled Microsoft Decoder by renaming its 2 files in System folders, but now MPC Audio Decoder is used!
Noting that all the internal filters are unchecked and LAV was reinstalled.
Any idea how to prioritize/make LAV Audio decoder default in MPC ??
I'd really appreciate your help.
Thanks a lot!
Cheers,
Salaam
LDD9O
28th November 2015, 13:06
Wishlist/Suggestion:
Portable version or semi-portable version where setting can easily be stored/change/copy.
Alternatively:
Import/export setting
huhn
29th November 2015, 03:37
Hey guys,
My m2ts files Audio are decoded by Microsoft DTV-DVD Decoder instead of external LAV filters. (and yes, they're preferred and video decoder is working fine)
So I disabled Microsoft Decoder by renaming its 2 files in System folders, but now MPC Audio Decoder is used!
Noting that all the internal filters are unchecked and LAV was reinstalled.
Any idea how to prioritize/make LAV Audio decoder default in MPC ??
I'd really appreciate your help.
Thanks a lot!
Cheers,
Salaam
what audio codec is used here?
salam2009
29th November 2015, 23:20
@huhn
Player used is MPC-BE based on K-Lite Mega Codec Pack.
Played files are BluRay with DTS Audio.
Thanks so much for any tip!
nevcairiel
29th November 2015, 23:21
Sounds like you enabled Bitstreaming in LAV Audio but your audio renderer does not accept bitstreaming.
salam2009
30th November 2015, 00:13
@nevcairiel
Yes, I did actually and my Audio Renderer should support it.
Anyway, I disabled it then it surprisingly identified LAV Audio Decoder which output it as PCM!
I guess I should be good to go. Thanks for your precious input, buddy!
chros
30th November 2015, 11:30
and you are sure the HD 4000 isn't used with copyback?
Yes, (since we can't separate acceleration process from 2 cores, and my default player is assigned to nvidia), I just double checked it with few 2160p samples (on 1080p display) (I use the nvidia gpu in an underclocked state (470/800 vs 745/2000 (default))):
1. in underclocked state:
- DXVA Copyback direct can accelerate only: 24fps 33Mbitps, 25fps 16Mbitps
- CUVID can accelerate : 30fps 16Mbitps, 24fps 130Mbitps (!)
2. in default state:
- DXVA Copyback direct can accelerate only: 24fps 33Mbitps, 25fps 16Mbitps, 30fps 16Mbitps
- CUVID can accelerate : 24fps 130Mbitps (!)
(Bitrates are average bitrates according to mediainfo, bit it could get really high so that's when copyback fails.)
I understand that this is an extreme case, just wanted you to know how CUVID vs copyback behaves on my system.
My m2ts files Audio are decoded by Microsoft DTV-DVD Decoder instead of external LAV filters.
Sounds like you enabled Bitstreaming in LAV Audio but your audio renderer does not accept bitstreaming.
Sometimes I get this, I think (it didn't happen for a month or so) a reboot solves the problem for me. Thanks for the explanation!
nghiabeo20
30th November 2015, 12:25
I can't install LAV x64, even after I do a W10 clean install. I use MPC BE 32bit, and have a 64bit system. How to solve this? Thanks!
Sarasa
30th November 2015, 12:49
I can't install LAV x64, even after I do a W10 clean install. I use MPC BE 32bit, and have a 64bit system. How to solve this? Thanks!
LAV install the 32/64 version of the Splitter/Audio/video unless you deselect/don't select them on the install menu
MPC BE 32 / MPCHC 32 use Lav 32 (Splitter/Audio/video)
MPC BE 64 / MPCHC 64 use Lav 64 (Splitter/Audio/video)
So to answer your question, use a 64 bit player ;)
huhn
30th November 2015, 14:07
Yes, (since we can't separate acceleration process from 2 cores, and my default player is assigned to nvidia), I just double checked it with few 2160p samples (on 1080p display) (I use the nvidia gpu in an underclocked state (470/800 vs 745/2000 (default))):
1. in underclocked state:
- DXVA Copyback direct can accelerate only: 24fps 33Mbitps, 25fps 16Mbitps
- CUVID can accelerate : 30fps 16Mbitps, 24fps 130Mbitps (!)
2. in default state:
- DXVA Copyback direct can accelerate only: 24fps 33Mbitps, 25fps 16Mbitps, 30fps 16Mbitps
- CUVID can accelerate : 24fps 130Mbitps (!)
(Bitrates are average bitrates according to mediainfo, bit it could get really high so that's when copyback fails.)
I understand that this is an extreme case, just wanted you to know how CUVID vs copyback behaves on my system.
Sometimes I get this, I think (it didn't happen for a month or so) a reboot solves the problem for me. Thanks for the explanation!
think about quicksync.
25 FPS up to 16 mbit is a joke...
Nullack
1st December 2015, 09:31
Bit of a testing report. I managed to get a sample of UHD 4K content in HEVC with 10 bit colour in level 5.2 using a very high constant bitrate at 60 FPS. Its 3840x2160P60 as in the 4K TV standard not the cinema 4K. Using an old sandy bridge CPU and a Nvidia Geforce 960, setting the nightly x64 LAV filters with the nightly MPC-HC builds, on my 4K display I see it render smooth and flawless. I run DXVA 2 in native mode using the EVR CP. At 60 fps it takes around 16.6 ms for each frame, and Im pleased to say my max paint times in MPC-HC barely exceed this at around 25 ms, with most frames - well just about all of them - being well under the 16.6 ms cadence at 5 ms. I notice a CPU utilisation around 7% and the GPU video engine peaks at 62% max, the gpu core peaks at 61% and on my 2GB card, the video ram use maxes out at 75%. Overall its a very pleasant experience with excellent video quality, crisp and sharp, played back using barely any CPU and the GPU doing the grunt. Even with 60 FPS material of such complexity its all smooth.
chros
1st December 2015, 11:47
think about quicksync.
25 FPS up to 16 mbit is a joke...
:) I know, but it was for testing purposes.
If I use quicksync then I'm forced to use iGPU. So it's not enough for madvr :)
huhn
1st December 2015, 22:47
:) I know, but it was for testing purposes.
If I use quicksync then I'm forced to use iGPU. So it's not enough for madvr :)
no that shouldn't be the case.quicksync should be working in headless mode not even optimus should be able to break that.
salam2009
2nd December 2015, 01:45
Hey huhn,
Which Audio Renderer do you think is recommended in MPC for WASAPI (shared mode): System Default, DirectSound: Samsung HTIB via HDMI or MPC-BE Renderer?
Thank you so much indeed :)
huhn
2nd December 2015, 05:39
I don't know any benefits from shared WASAPI over directsound.
so i guess the new internal MPC-HC audio renderer.
Aleksoid1978
2nd December 2015, 06:01
MPC-BE audio renderer :)
salam2009
2nd December 2015, 06:40
Thanks both for the awesome tip :)
JarrettH
2nd December 2015, 19:23
DXVA2 copyback is a good/better alternative.
If you have a fast CPU, then software decoding is the best choice imho. It is simply more reliable than hardware acceleration. Quality is the same.
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 :sly:
Asmodian
3rd December 2015, 01:37
madVR's render time is not decoding time, madVR's OSD does not display video decoding times. A Core 2 Duo is a slow CPU today but still fast enough for 1080p H.264 software decoding, 4K or HEVC might cause you some trouble though.
Of course madVR will run faster when it doesn't have to share the GPU with DXVA2 decoding. DXVA2 decoding uses dedicated hardware on the GPU (not shaders) but it still impacts madVR a little bit.
Nullack
3rd December 2015, 08:38
Hi, whats the situation with VP9? During playback the EVR-CP renderer stats says its not using DXVA. I thought the GTX 960 gpu supported VP9 in full hardware GPU accel? Thx
EDIT: DXVAChecker says VP9_VLD_Profile0: DXVA2/D3D11, SD / HD / FHD / 4K so its in the GTX 960 hardware for sure
sneaker_ger
3rd December 2015, 08:47
LAV does not yet support VP9 DXVA. The author said he's already working on it, though.
http://forum.doom9.org/showpost.php?p=1746013&postcount=896
nevcairiel
3rd December 2015, 09:48
The latest NVIDIA driver also seems to not support VP9 properly yet.
chros
3rd December 2015, 11:38
Of course madVR will run faster when it doesn't have to share the GPU with DXVA2 decoding. DXVA2 decoding uses dedicated hardware on the GPU (not shaders) but it still impacts madVR a little bit.
Really? I'll check it during the weekend, just out of curiousity :)
clsid
3rd December 2015, 16:19
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 :sly: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
4th December 2015, 07:24
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
4th December 2015, 11:22
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
4th December 2015, 21:36
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
6th December 2015, 03:59
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
6th December 2015, 04:29
EVR-CP can't accept 10-bit
Aleksoid1978
6th December 2015, 06:56
EVR-CP can accept P010 if use DXVA decoder, for HEVC MAIN 10 decoder.
NikosD
6th December 2015, 07:53
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
6th December 2015, 12:17
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
6th December 2015, 12:24
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
6th December 2015, 12:26
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
6th December 2015, 12:27
Maybe a sample could help
nevcairiel
6th December 2015, 12:36
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
6th December 2015, 12:55
I got an answer from NVEncC's developer that it uses "pure CUVID decoding" which is "stable enough"
Case solved.
Nullack
7th December 2015, 06:21
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
7th December 2015, 09:39
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
7th December 2015, 09:42
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
8th December 2015, 07:05
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
8th December 2015, 07:16
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
8th December 2015, 07:27
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.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.