View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
nevcairiel
12th August 2017, 14:59
It probably requires Windows 8 or newer, but should otherwise work. Its unclear yet if it can be made work on 7 properly. More details will be announced later.
madshi
12th August 2017, 15:10
I believe it will only work in Windows 8+, based on this:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb173059(v=vs.85).aspx
DXGI_FORMAT_NV12
[...]
Direct3D 11.1: This value is not supported until Windows 8.
However, some of the things that used to only work on Windows 8, are working in Windows 7 after having installed the Platform Update, so it's not 100% clear just yet. But my guesstimate is that it won't work in Windows 7.
clsid
12th August 2017, 15:41
It doesn't work here on 7 (with platform update).
nevcairiel
12th August 2017, 15:43
To get it to work on 7 at all you can load the decoder through the d3d11 api with a DX 9.3 profile, the DX11.1 profile doesn't work on 7. Alas, this is not done. But I do not know if it would still break on creating NV12 textures, though.
In any case, I need to setup 7 on an actual hardware box to see about this at a later time.
el Filou
12th August 2017, 16:44
Hi nev, does that mean we'll be able to use that decoder to get bit exact quality chroma input with madVR without having to use DXVA2 Copy-Back?
DXVA2 Copy-Back suffers from much lower decode performance on my old system (can't watch 4K50/60), even with a modern graphics card, so that would be awesome news.
FDisk80
12th August 2017, 19:07
Well if you upgrade 3 components in one go, then isolating the problem to one particular component should be the first step, instead of randomly guessing what might be to blame. :)
The NVIDIA drivers also sometimes reset their power management on upgrades, it should be Adaptive at least, Optimimum Power is too aggressive in power savings. CUVID can work around that particular issue by forcing the GPU into max power mode (which is a sideeffect of using CUDA).
It was the 8-bit H264 -> 10-bit P010 output format conversion.
Enabling 8-Bit NV12 output format solved the DXVA2 (copy-back) issue.
nevcairiel
12th August 2017, 21:05
It was the 8-bit H264 -> 10-bit P010 output format conversion.
Enabling 8-Bit NV12 output format solved the DXVA2 (copy-back) issue.
That might do it. It would disable direct mode, which increases performance cost, on top of needing extra processing anyway.
Its always best to output as close to the original as you can (basically, don't turn stuff off).
ryrynz
12th August 2017, 22:18
DXVA2 Copy-Back suffers from much lower decode performance on my old system (can't watch 4K50/60), even with a modern graphics card, so that would be awesome news.
Grab the nightly and test.
nevcairiel
12th August 2017, 22:20
Clearly such a feature would require support in the renderer as well, so watch out for that. :) Without that, it only does copy-back, although it appears even to be a tad bit faster then DXVA2-CB, not that this would really matter in playback scenarios.
DragonQ
16th August 2017, 15:13
I currently have a Celeron G530 (2c/2t Sandy Bridge @ 2.4 GHz) in my HTPC, which is used pretty much only for HEVC playback since my GT 430 handles MPEG2, MPEG4, and AVC. I have a Celeron G1620 (2c/2t Ivy Bridge @ 2.7 GHz) in my file server. I also have a spare Core i3-3220 (2c/4t Ivy Bridge @ 3.3 GHz), which I want to put into one of those two systems, depending on where it'd be most useful. Would there be any benefit in terms of improved HEVC decoding ability if I put either the Core i3-3320 into the HTPC? For example, being able to handle higher bit rates or colour depths? I'm struggling to find benchmarks of software HEVC decoding using avcodec.
EDIT: If there's a better thread to ask this in please let me know.
el Filou
16th August 2017, 22:04
@DragonQ personally, I'd put the i3 in the HTPC. If the only thing your server is doing is serving files, then a faster CPU won't change much as it's pretty much only the storage subsystem and RAM that matters.
Grab the nightly and test.Minimum frame rate is better, but still no luck overall:
0.70.2: 36-41 fps
0.70.2-35: 39-41 fps
I think my chipset/RAM is really too slow.
(FYI, 0.70.2-35 DX11: 32-33 fps)
nevcairiel
17th August 2017, 01:33
For the real gain you'll need to wait for an updated madVR - which is scheduled for sometime this week. Note that you won't really be able to benchmark that mode, since only madVR will be able to understand it (for now), but you can of course do real-world tests to see if it works smoothly.
Performance wise I would expect it to be similar to DXVA2 native, without the quality drawbacks.
DragonQ
17th August 2017, 10:04
@DragonQ personally, I'd put the i3 in the HTPC. If the only thing your server is doing is serving files, then a faster CPU won't change much as it's pretty much only the storage subsystem and RAM that matters.
I think you're right that most of the stuff it does is I/O or bandwidth limited rather than CPU limited:
Serving files
Serving Windows Updates
Calculating FlexRAID parity nightly*
Backup files nightly
Running background downloads
Hosting a VPN
Hosting a web server (file sharing, SubSonic, WebMediaPortal, etc.)
The starred item would probably benefit from greater CPU power but it's rare that it has to do a long recalculation anyway. Whenever my girlfriend upgrades her gaming PC I'll be able to nab her Core i5-2500K too but that could be years away. I could even retire my X5650 system but that'd be a terrible server since it uses so much power!
huhn
17th August 2017, 21:04
is d3d11 headless mode also planned for the next release?
DragonQ
18th August 2017, 17:31
Using my AMD RX 480, when I attempt to play this sample file (https://drive.google.com/file/d/0BwxFVkl63-lEdVBuZkltckdZZ0k/view) (2160p60, HEVC, 10b, 25 Mb/s) at 1440p using DXVA2 copy-back I get 100% GPU usage and it's nowhere near playable. Same for CPU decoding, even with 12 virtual cores. However, when I play it using DXVA2 native, I just get a black screen. The GPU is doing something since usage is around 50% and MadVR says frames are taking ~10 ms to render, but I can't see anything. Should I be able to play this file using DXVA2 native using this GPU?
I even tried turning everything in MadVR down to nearest neighbour but it made no difference to either the GPU usage or black screen.
nevcairiel
18th August 2017, 18:19
Should I be able to play this file using DXVA2 native using this GPU?
10-bit DXVA2-Native is rather broken on AMD in conjunction with madVR (driver bugs, i'm told).
You can try a nightly LAV and the latest madVR, and test D3D11 mode - assuming you are on Windows 8 or newer.
aufkrawall
18th August 2017, 19:38
Thx a lot for D3D11VA support, nev.
I did some tests and here are my conclusions vs. DXVA2 (copyback) regarding quality on a GTX 1070 with driver 385.28 on Windows 10 Creators Update 1 + madVR (deband off, dithered 8 bit output):
DXVA2 native doesn't show banding anymore (?) with HEVC 10 bit Rec.709 content
DXVA2 native shows most excessive banding with HEVC 10 bit Rec.2020 HDR content
It still shows nasty chroma blur with H.264 8 bit
I don't have a proper sample to test chroma blur with 10 bit content, so can't say if it would also show chroma blur with DXVA2 native (I personally would expect the worst)
It seems DXVA2 native doesn't increase banding anymore (?) of 8 bit H.264 sources
D3D11VA doesn't seem to show any banding at all with any of the mentioned content
D3D11VA also doesn't show any chroma blur
Both points also apply to DXVA2 copyback (of course we already knew that)
And now, a interesting point which has often been excluded: performance.
I assumed my graphics card's power consumption by multiplying the average percentage value of the reported power target with the card's measured 100% power target, which is ~180W for this MSI 1070 Gaming X. Nvidia Inspector and hwinfo64 can read out values in Watts, but they don't seem to be realistic for some reasons (way too high).
I again tested with a HEVC 10 bit Rec.2020 HDR 4k 60fps video, downscaled to 1440p with reasonable quality settings.
d3d11va: ~32% Power -> ~58W ~55% GPU usage @ 1.45GHz @ 2.3GB VRAM
dxva2-copyback: ~54% Power -> ~97W ~68% GPU usage @ 2GHz 2.5GB VRAM
So, copyback mode can have a huge impact on power consumption and performance, and even may prevent you from using better madVR quality settings.
-> D3D11VA seems to be golden.
BetA13
18th August 2017, 21:38
hmmm, just a quick question.
The DXVA11 mode doesnt work for win 7, does it?
cause it doesnt work for me, it uses CPU instead..i mean the GPU isnt listed and not used when using DXVA11..
sorry if this has allready been answered but i didnt find it..
greetz
Zetti
18th August 2017, 22:33
hmmm, just a quick question.
The DXVA11 mode doesnt work for win 7, does it?
cause it doesnt work for me, it uses CPU instead..i mean the GPU isnt listed and not used when using DXVA11..
sorry if this has allready been answered but i didnt find it..
greetz
Read nevcairiel's last post in post #22109
nevcairiel
18th August 2017, 23:27
D3D11 decoding is not supported on Windows 7, and after some testing it also seems like that won't change. The NV12 texture format is not available on 7, which makes the entire process impossible.
One could perhaps do a low-quality thing that outputs RGB directly, but we already have DXVA2-Native which operates on a similar concept.
I'll probably add a note about that in the LAV config. I thought about just hiding the option entirely, but perhaps its good to show people what they are missing (also, they might come here asking where it is since they heard about it)
mitchmalibu
19th August 2017, 01:20
Just wanted to say, really great stuff on the DXVA11 mode: it handles my hdr 60fps demo clips perfectly, which I wasn't able to do previously. Between you and madshi, the htpc world really made huge steps forward in a matter of months.
DragonQ
19th August 2017, 01:49
10-bit DXVA2-Native is rather broken on AMD in conjunction with madVR (driver bugs, i'm told).
You can try a nightly LAV and the latest madVR, and test D3D11 mode - assuming you are on Windows 8 or newer.
I'm running the latest MadVR and latest LAV Filters nightly but still get a black screen in DXVA2 native. I'm currently on the previous WHQL driver (17.4.4) due to severe game performance issues with the latest one (17.7.2), I wonder if that driver solves this problem?
However, D3D11 mode seems to work. I can play the sample clip in fullscreen with ~50% GPU usage using "ReconSoft" chroma and "Catmull-Rom AR" luma. :)
ryrynz
19th August 2017, 05:33
Why wonder? Take you a few minutes to know for certain.
mogli
19th August 2017, 07:51
I saw the video decoder showing D3D11 cb direct mode instead of native. How and why is that activated?
madshi
19th August 2017, 08:07
LAV auto switches to D3D11 copyback ("D3D11 cb") if the video renderer doesn't support the required communication interface for native D3D11 DXVA. So e.g. if you activate D3D11 decoding for EVR, or for an old (anything older than 0.92.0) madVR version, you'll get D3D11 copyback.
mogli
19th August 2017, 08:27
OK, but renderer was madVR 0.92.1 which generally uses D3D11 native. Maybe just a hickup.
madshi
19th August 2017, 08:48
If you can find a way to reproduce it somehow, please let us know how!
nevcairiel
19th August 2017, 09:04
Of course there also cannot be anything between LAV Video and madVR, ie. no ffdshow video processing or anyhting of that sort. native requires a clean direct connection.
strumf666
19th August 2017, 09:19
That includes ffdshow raw which is needed for SVP? And SVP?
ryrynz
19th August 2017, 09:25
Yes, as Nev said, nothing between LAV and madVR.
strumf666
19th August 2017, 09:28
No offense, I would like a confirmation from Nev or Madshi.
rock
19th August 2017, 09:48
sample
https://drive.google.com/file/d/0B3v0PVuQfH99TktaTHpBMWtNXzA/view?usp=sharing (got this sample from someone on CCCP forums)
this cut plays file with MPC-HC v1.7.13.65 (LAVFilters v0.70.2.1) and looks like capture below with MPC-HC v1.7.13.89 (LAVFilters v0.70.2.35)
capture
https://drive.google.com/file/d/0B3v0PVuQfH99WmNRejRCSkhaUHM/view?usp=sharing
ryrynz
19th August 2017, 09:56
No offense, I would like a confirmation from Nev or Madshi.
It's a direct interface, ffdshow hasn't been developed for years. Of course it's not going to support a new interface just recently developed. No lines to read between here..
nevcairiel
19th August 2017, 10:01
That includes ffdshow raw which is needed for SVP? And SVP?
"no ffdshow or anything" should have been pretty clear. Post-processing filters of any sort don't get access to the image when this is used.
Its the same limitation that DXVA2-Native had. It requires a direct connection between decoder and renderer, no intermediate steps.
nevcairiel
19th August 2017, 10:03
sample
https://drive.google.com/file/d/0B3v0PVuQfH99TktaTHpBMWtNXzA/view?usp=sharing (got this sample from someone on CCCP forums)
this cut plays file with MPC-HC v1.7.13.65 (LAVFilters v0.70.2.1) and looks like capture below with MPC-HC v1.7.13.89 (LAVFilters v0.70.2.35)
capture
https://drive.google.com/file/d/0B3v0PVuQfH99WmNRejRCSkhaUHM/view?usp=sharing
Old x264 4:4:4 predictive (lossless) encodes are not standards conformant, and if someone had the brilliant foresight to remove the x264 metadata that identifies them as such, then it cannot be helped.
Standards conformant decoding will always be preferred, for a simple reason: You can identify broken x264 encodes (if the metadata has NOT been removed), but you cannot do the opposite (ie. identify a file as being encoded properly, one has to assume that).
sneaker_ger
19th August 2017, 10:49
Best to decode these older lossless files with older ffmpeg and encode with recent x264 (add --no-8x8dct for best compatibilty with older ffmpeg). We discussed that in the x264 dev thread.
/edit:
Ah, the sample isn't lossless. With non-lossless 4:4:4 you are kinda fucked because you can't fix it losslessly.
and if someone had the brilliant foresight to remove the x264 metadata
Probably just because of the mkvmerge splitting. The metadata-SEI is only at the first GOP so only the first part will have it after splitting. No splitting, no problem.
DragonQ
19th August 2017, 13:27
Why wonder? Take you a few minutes to know for certain.
By a few minutes you mean about an hour (to upgrade, redo my GPU undervolt and overclock, do some testing, run DDU, reboot, reinstall old drivers, reconfigure monitor FreeSync range, redo GPU undervolt and overclock again). I've tried 17.7.2 driver twice already and both times had to revert due to gaming issues, I don't want to waste time again until they at least release a new version.
ryrynz
19th August 2017, 13:36
Create a restore point, upgrade, test and possibly restore back. Or will that not work? Skip the other things to test what matters, the driver.
nussman
19th August 2017, 16:16
Hi nevcairiel,
there seems to be a problem with "onthefly" format changes when using LAV DXVA D3D11 native with madVR.
I am using DVBViewer for LiveTV and the player freezes when I am zapping i.e from ARD HD (H.264 720p50) to ServusTV HD (H.264 1050i50).
DVBViewer (by default) does not rebuild the directshow graph if you zapping from h.264 to another h.264 channel, but you can force DVBViewer to do a rebuild on every channel Change and that fixes the problem (but increases zapping times a little bit ;) ).
By the way "onthefly" changes are working with EVR Renderer and DXVA D3D11 copyback.
P.S.
My system: Win 8.1, AMD RX 460
and thanks for the new version. :)
nevcairiel
19th August 2017, 16:19
I am using DVBViewer for LiveTV and the player freezes when I am zapping i.e from ARD HD (H.264 720p50) to ServusTV HD (H.264 1050i50).
Size changes are not fully supported yet, it appears madVR needs to change something to make that work still, but we're on it.
Note that deinterlacing of any sort is also not available with D3D11-Native mode quite yet, so for TV it may not be the best choice yet.
madshi
19th August 2017, 18:14
Size changes are not fully supported yet, it appears madVR needs to change something to make that work still, but we're on it.
Yes, that part is madVR's fault. nevcairiel already notified me about this problem before 0.92.0 release, but I decided to release 0.92.0, anyway, so users could already start testing...
DragonQ
19th August 2017, 23:45
I currently have a Celeron G530 (2c/2t Sandy Bridge @ 2.4 GHz) in my HTPC, which is used pretty much only for HEVC playback since my GT 430 handles MPEG2, MPEG4, and AVC. I have a Celeron G1620 (2c/2t Ivy Bridge @ 2.7 GHz) in my file server. I also have a spare Core i3-3220 (2c/4t Ivy Bridge @ 3.3 GHz), which I want to put into one of those two systems, depending on where it'd be most useful. Would there be any benefit in terms of improved HEVC decoding ability if I put either the Core i3-3320 into the HTPC? For example, being able to handle higher bit rates or colour depths? I'm struggling to find benchmarks of software HEVC decoding using avcodec.
EDIT: If there's a better thread to ask this in please let me know.
Replaced the Celeron G530 with the Core i3-3220. HEVC Benchmark Tool scores have increased by ~60% (surprised it wasn't higher since it has a 38% higher clock speed plus SMT). According to that it should be able to handle 1080p24 HEVC at all realistic bit rates and 2160p24 HEVC at up to ~10 Mb/s but I'm not sure if the benchmark is for Main or Main 10. Most 2160p sample videos I have are either AVC or 60 FPS (which it'll have no chance with)...will have to hunt down some more!
aufkrawall
20th August 2017, 15:48
With new nightlies, you can select the device for d3d11va. However, it doesn't stick yet and thus doesn't work.
Tested with Skylake IGP.
mrcorbo
20th August 2017, 17:14
With new nightlies, you can select the device for d3d11va. However, it doesn't stick yet and thus doesn't work.
Tested with Skylake IGP.
Is it because of this?
"The selected D3D11 device is only used in copy-back mode. In native mode the renderer determines the device used."
nevcairiel
20th August 2017, 17:32
With new nightlies, you can select the device for d3d11va. However, it doesn't stick yet and thus doesn't work.
Tested with Skylake IGP.
I didn't quite finish this last night, but the next build should properly save and load the setting. As mrcorbo said, it won't work in native mode however.
aufkrawall
20th August 2017, 17:50
"not in native mode" means it looks like software decoding to the renderer? Does that come with any drawback?
Edit: What comes to my mind is that probably no deinterlacing can be done on the GPU which isn't used for rendering.
Could d3d11va deinterlacing be faster than the current deinterlacing used by madVR and which also works with software decoding/copyback?
nevcairiel
20th August 2017, 18:00
"not native mode" means copy-back, just like with DXVA2.
aufkrawall
20th August 2017, 18:10
"not native mode" means copy-back, just like with DXVA2.
I thought so. Well, I don't think that's any problem since there has to be copying anyway and it probably won't load additional load on the dGPU, unlike copyback used on the same GPU for both rendering and decoding.
Or am I missing something?
XinHong
20th August 2017, 18:59
Is it possible to get D3D11VA without a D3D11 graphics card ?
Because I have an Intel HD3300 (DirectX 10.1) & MadVR 0.92.1 and I get a green screen. If I switch to the GT525M (DirectX 11) it's OK.
Thanks
aufkrawall
20th August 2017, 19:03
Yes, I tested it on a 9600 Gt on Windows 10. However, madVR isn't working with DX11 on this card, and with DX9, the decoder falls back to copy mode (and so it's also the case for EVR).
Edit: oh, you mentioned a green screen. That's the result I got as well.
So either it's not working in native mode without DX11 hardware, or madVR DX11 doesn't work with non-DX11 hardware (I'd probably bet on the latter one).
Edit: Windows 10 video app uses DX11, so it uses D3D11VA decoding as well. It works without a green screen on the 9600 Gt. Very likely a madVR issue then.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.