View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
aufkrawall
15th February 2015, 19:32
That's good. Do you also know if H.264 decoding has become faster?
afair, with GM204 it's still slower than Haswell (e.g. too slow for 4k lossless).
nevcairiel
15th February 2015, 19:47
Lossless decoding is not supported in hardware on any device.
The speed is the same however, around 80-90 fps on complex H264 4K.
aufkrawall
15th February 2015, 19:50
Ah, yes. File has crf 1, not 0.
Deihmos
16th February 2015, 00:18
I normally just install the splitter. The new version .64 fails with an error. I am using win 8.1 64bit. It installed fine if I install all the filters but I only use the splitter.
https://dl.dropboxusercontent.com/u/61945547/Capture.PNG
nevcairiel
16th February 2015, 01:15
I normally just install the splitter. The new version .64 fails with an error. I am using win 8.1 64bit. It installed fine if I install all the filters but I only use the splitter.
https://dl.dropboxusercontent.com/u/61945547/Capture.PNG
Fixed the dependencies in the installer for the next version.
Deihmos
16th February 2015, 01:16
Thanks. I will look out for the next version.
sdancer75
16th February 2015, 09:17
I created an async AVI source filter that works just fine with the original avi splitter but with the LavSplitter I get some incompatibilities.
This means, that under graphedit, the graph is not starting at all, but if I scroll forward the graphedit progress bar then it plays just fine.
Can you recommend anything to change inside my code ? I am attaching you my source filter.
Best Regards,
PS:Where to see inside your LavSplitterSource to change the offset (in bytes) from the start of the input video file ?
eddman
16th February 2015, 17:54
Both 8 and 10-bit are 100% decoded by a dedicated ASIC on the GTX 960.
What?! I didn't expect that. I thought only tegra X1 had 10-bit support. Now that's a nice surprise.
Is that for h.265 only?
P.J
17th February 2015, 20:34
The most you can do is change the mixing levels from 0.71 to 1.0. Otherwise you'll need something like ffdshow.
It doesn't work, think I have to leave LAV Audio :(
huhn
17th February 2015, 20:48
nearly all player have this option.
mpc-HC and BE have audio boost. AC3 filter has DRC function.
all can destroy audio quality by the way...
iSunrise
17th February 2015, 23:00
What?! I didn't expect that. I thought only tegra X1 had 10-bit support. Now that's a nice surprise.
Is that for h.265 only?
Tegra X1 is documented to have a 4K60fps decoder (http://images.anandtech.com/doci/8811/Tegra%20X1%20Spec.PNG), while the decoder on GM206 seems even more powerful. Both need to support HEVC 10-bit, because it apparently was designed to meet the new Ultra HD Blu-ray standard.
ryrynz
18th February 2015, 09:01
I've found partially downloaded MKV files to continue playing audio but not refresh video when it continues to the next downloaded piece in the file.
Changing the video window size in any manner will force a refresh of the video and it displays normally, could LAV detect that the video has been interrupted and refresh itself automatically?
foxyshadis
18th February 2015, 09:05
Anyway to boost the volume in stereo ac3 tracks? PowerDVD can do it very well but LAV Audio :(
Use ffdshow with only raw audio processor installed, it'll run after LAV. You can do whatever you want to the sound then.
This is the way it SHOULD be done, and it's only not because Directshow is a PITA and players don't cooperate to make it simpler (or handle it all themselves), so everyone wants all the functionality built into a single filter. There are tons of audio processing filters out there, most non-free, but ffdshow has a lot of basic capabilities.
yonta
18th February 2015, 10:20
Starting from v1.7.7.174 mpc-hc crashes on some youtube vp9 webm files. It's not only mpc-hc's problem because latest mpc-be/mplayer/mpv all crash on the same files. I've found the last working mpc-hc version is v1.7.7.157.
sample (https://drive.google.com/file/d/0B1mCVSSmbT2LcW9pajdYMGFtX1E/view?usp=sharing)
eddman
18th February 2015, 14:36
Tegra X1 is documented to have a 4K60fps decoder (http://images.anandtech.com/doci/8811/Tegra%20X1%20Spec.PNG), while the decoder on GM206 seems even more powerful. Both need to support HEVC 10-bit, because it apparently was designed to meet the new Ultra HD Blu-ray standard.
Yes, I knew about the X1.
I also knew that GM206's HW decoder supports h.265, it's just that nvidia didn't mention 10-bit support.
Thanks for the info about Ultra HD blu-ray.
I just wonder if it supports 10-bit HW decoding for h.264 too, but since commercial hardware stick to the first version of codecs apparently, perhaps not, which is a shame.
nevcairiel
18th February 2015, 14:38
I just wonder if there is 10-bit decoding for h.264 too, but since commercial hardware stick to the first version of codecs, perhaps not, which is a shame.
Commercial Hardware sticks to codecs with commercial interest, and there is absolutely zero commercial content in H.264 10-bit, so there is no logic in supporting that.
wanezhiling
18th February 2015, 16:06
So the native dxva decoder for h.265 10-bit will never be implemented before microsoft makes some changes?
huhn
18th February 2015, 19:28
So the native dxva decoder for h.265 10-bit will never be implemented before microsoft makes some changes?
maybe with madVR.
but very unlikely we see it with directshow EVR.
maybe media foundation EVR can do it but that would mean all directshow filter needs to be rewritten for media foundation very unlikely any time soon.
sdancer75
19th February 2015, 10:11
I created an async AVI source filter that works just fine with the original avi splitter but with the LavSplitter I get some incompatibilities.
This means, that under graphedit, the graph is not starting at all, but if I scroll forward the graphedit progress bar then it plays just fine.
Can you recommend anything to change inside my code ? I am attaching you my source filter.
Best Regards,
PS:Where to see inside your LavSplitterSource to change the offset (in bytes) from the start of the input video file ?
Problem found ! The problem with the original code, was the check of the pllAvailable variable.
So, the original code, returns zero (0) for the pllAvailable all the time.
Mysteriously, AVISplitter handled somehow this error, and it worked just fine.
HRESULT CAsyncIo::Length(LONGLONG *pllTotal, LONGLONG *pllAvailable) {
CheckPointer(pllTotal,E_POINTER);
HRESULT hr = S_OK;
LONGLONG llAvailable = 0;
hr = m_pStream->Length(pllTotal, &llAvailable);
// *pllAvailable can be NULL.So dont pass anything if pointer does not exist
if (pllAvailable != NULL) /* original code if (*pllAvailable) returns always false */
*pllAvailable = llAvailable;
//Despite of the original error, it worked just fine with AVISplitter but not
//with the LavSplitter
return hr;
}
Nintendo Maniac 64
20th February 2015, 09:14
So uh, question - I'm using the newest LAV v0.64 in MPC-HC 64bit v1.7.8 and I'm wondering how do I take advantage of the super-low CPU-usage mode or whatever in DXVA2 copy-back? I'm using a stock MPC-HC and I get pretty much the same CPU utilization on QuickSync as I do copy-back while native is much lower...
Do I need an HSA/hUMA compatible AMD APU or something to take advantage of the super-efficient DXVA2 copy-back? For refreence my CPU is a Pentium G3258 and my GPU is the integrated Intel Haswell graphics.
I've been testing with the 1080p 60fps h.264 version of this YouTube video:
https://www.youtube.com/watch?v=5I-nQtsJuhE
Starting from v1.7.7.174 mpc-hc crashes on some youtube vp9 webm files. It's not only mpc-hc's problem because latest mpc-be/mplayer/mpv all crash on the same files. I've found the last working mpc-hc version is v1.7.7.157.
sample (https://drive.google.com/file/d/0B1mCVSSmbT2LcW9pajdYMGFtX1E/view?usp=sharing)
No crash over here on MPC-HC v1.7.8 + LAVFilters v0.64, and that's in both the 32bit and 64bit versions.
Also that's the first video I've ever seen where it being recorded vertically makes more sense (at that distance recording horizontally would have resulted in cropped off head or legs)
NikosD
20th February 2015, 12:58
So uh, question - I'm using the newest LAV v0.64 in MPC-HC 64bit v1.7.8 and I'm wondering how do I take advantage of the super-low CPU-usage mode or whatever in DXVA2 copy-back? I'm using a stock MPC-HC and I get pretty much the same CPU utilization on QuickSync as I do copy-back while native is much lower...
Do I need an HSA/hUMA compatible AMD APU or something to take advantage of the super-efficient DXVA2 copy-back? For refreence my CPU is a Pentium G3258 and my GPU is the integrated Intel Haswell graphics.
I've been testing with the 1080p 60fps h.264 version of this YouTube video:
https://www.youtube.com/watch?v=5I-nQtsJuhE
Using a Win 8.1 Pro x64 system with HD 4600 (Core i7-4790), I can't see a real difference between QS and DXVA-CBD for that clip during playback mode.
When I measured normal playback, CPU utilization was about the same, just like Power consumption.
If you push the test to the limits by doing some benchmark test in Playback mode, then you 'll see that CPU utilization using QS decoder is 3 times more than DXVA-CBD.
And the power consumption is about 50% more, with only 10% faster framerate for QS.
So, it sure works.
No crash over here on MPC-HC v1.7.8 + LAVFilters v0.64, and that's in both the 32bit and 64bit versions.
Also that's the first video I've ever seen where it being recorded vertically makes more sense (at that distance recording horizontally would have resulted in cropped off head or legs)
It's crashing for me too ,like the original poster.
bcec
20th February 2015, 18:48
If I want MadVR to be the one performing chroma conversion for 4:2:0 sources to 4:4:4, what should I select in Lav Decoder options?
Currently, I have everything checked in Output Formats, and RGB Output Levels is set to Untouched.
detmek
20th February 2015, 19:17
Leave as it is. LAV Video decoder will always output same colorspace format as long as render can accept it. Since madVR accepts 4:2:0 LAV Video decoder will output 4:2:0 if it is a source colorspace/color subsample format.
RGB output levels are only used if LAV Video decoder converts source format to RGB. Else, it does nothing.
bcec
20th February 2015, 23:22
Leave as it is. LAV Video decoder will always output same colorspace format as long as render can accept it. Since madVR accepts 4:2:0 LAV Video decoder will output 4:2:0 if it is a source colorspace/color subsample format.
RGB output levels are only used if LAV Video decoder converts source format to RGB. Else, it does nothing.
Thank you!
Nintendo Maniac 64
21st February 2015, 05:41
If you push the test to the limits by doing some benchmark test in Playback mode, then you 'll see that CPU utilization using QS decoder is 3 times more than DXVA-CBD.
Ok, that's great and all, but what does "push the test to the limits" mean? A 4k 60fps video?
It's crashing for me too ,like the original poster.
Ok, but what version of MPC-HC and LAVFilters are you using?
Aleksoid1978
21st February 2015, 05:50
Hi nevcairiel.
I buy GTX 960, test LAV Video Decoder on HEVC 10bit, then modify MPC-BE's video decoder. And ... perfect work DXVA HEVC 10bit, EVR Custom accept P010 DXVA input.
Here test build - http://aleksoid.voserver.net/MPC-BE/mpc-be.exe_DXVA_HEVC_4K_10Bit.7z
NikosD
21st February 2015, 08:22
Ok, that's great and all, but what does "push the test to the limits" mean? A 4k 60fps video?
Pushing to the limit, depends on the system - CPU and GPU.
For example, it means go in benchmark mode.
In real life, means something more difficult than that clip - which has a very low bitrate btw.
Ok, but what version of MPC-HC and LAVFilters are you using?
1.7.8.61 and 0.64
huhn
21st February 2015, 12:31
Hi nevcairiel.
I buy GTX 960, test LAV Video Decoder on HEVC 10bit, then modify MPC-BE's video decoder. And ... perfect work DXVA HEVC 10bit, EVR Custom accept P010 DXVA input.
Here test build - http://aleksoid.voserver.net/MPC-BE/mpc-be.exe_DXVA_HEVC_4K_10Bit.7z
is it supposed to accept P010 from software decoder too or only from DXVA?
MrC
22nd February 2015, 15:55
Hi nevcariel,
first of all thanks for the new 0.64 release.
Do you see any possibility to implement the 5.0 audio channels configuration support in the future?
http://forum.doom9.org/showthread.php?p=1701021#post1701021
Thanks in advance
;)
Bye
RealSnoopyDog
22nd February 2015, 17:38
@nev: You should change the release date in the first post to 2015 ;)
Changelog
0.64.0 - 2016/02/13 - Release Notes
DragonQ
22nd February 2015, 22:17
Hi nevcariel,
first of all thanks for the new 0.64 release.
Do you see any possibility to implement the 5.0 audio channels configuration support in the future?
http://forum.doom9.org/showthread.php?p=1701021#post1701021
Thanks in advance
;)
Bye
What's the reason for requiring this? Can you not just set it to 5.1 and then tell either your AVR or Windows that you don't have a subwoofer?
foxyshadis
23rd February 2015, 02:07
What's the reason for requiring this? Can you not just set it to 5.1 and then tell either your AVR or Windows that you don't have a subwoofer?
I'm sure he wants the LFE mixed into the speakers. I would just disable LAV's mixer and add ffdshow to the chain to transform into custom formats.
Nintendo Maniac 64
23rd February 2015, 06:50
I can finally confirm for myself that copy-back does indeed use less CPU than QuickSync, though you need something like 4k resolution to really see the difference in CPU utilization. Oddly enough though, 4k 60fps seems to run at around 30fps in copy-back but seems to do around 40fps in QuickSync (native DXVA2 can do the full 60fps).
Either way, it's still not lower than native DXVA2 - maybe that is what would require some HSA/hUMA capabilities? (I'm not on Kaveri, so...)
sheppaul
23rd February 2015, 07:02
Oddly enough though, 4k 60fps seems to run at around 30fps in copy-back but seems to do around 40fps in QuickSync
It means the actual performance of quicksync is better than copy-back regardless of cpu usage.
it's still not lower than native DXVA2
You must be joking. It's simply impossible to exceed DXVA2 as copy-back operation is occurring after DXVA2 decoding.
Nintendo Maniac 64
23rd February 2015, 07:17
You must be joking. It's simply impossible to exceed DXVA2 as copy-back operation is occurring after DXVA2 decoding.
Then what the heck is this guy smoking?
I did a quick test on DXVA copy-back between the last two versions 0.67 vs 0.64.
I used Core i7-4790 and iGPU HD 4600 in Playback Performance benchmark mode at 1280x720 on two HEVC files (1080p & 2160p)
The results are impressive.
Huge drop of CPU usage about 40% for 1080p with a slight increase in performance ~10%
Big drop of CPU usage about 30% for 4K with a significant 40% increase in performance!
DXVA native in Playback Performance uses more CPU than DXVA copy-back!
My question is if DXVA native could benefit from these optimizations, too.
Also, I've been throwing around HSA/hUMA regarding copy-back since it was the only way I could imagine the above to be remotely possible, but does LAV even have any HSA/hUMA optimizations in the copy-back decoder?
NikosD
23rd February 2015, 08:31
Then what the heck is this guy smoking?
That guy is not smoking at all.
You have to be more polite and understand what you read, before you make such statements.
You have to leave your Nintendo for a while and think by yourself, doing a lot of tests and rethink about them.
I've been doing tests before you were born and that statement of mine was and is absolutely right.
If you don't understand what I wrote or if you are unable to reproduce it, ask me.
Maybe, after my instructions, you will be able to verify it by yourself, like you did with CBD vs QS cpu utilisation.
Nintendo Maniac 64
23rd February 2015, 09:04
Look, I have two different people telling me two completely contradictory things - I'm just completely and utterly baffled as to how the heck such a contradictory situation between what NikosD says and and what sheppaul refutes is even possible.
This is why I said about smoking something, because at this rate it feels like I'm the one that's doped up. Please don't shoot the messenger when they don't even have the slightest clue what to believe.
Is this even real life?
NikosD
23rd February 2015, 10:07
Probably you are doped up, because I'm NikosD and it was me that replied you before.
They are not contradictory what I and sheppaul say.
They refer to different situations.
I wrote above that DXVA-CBD has lower cpu utilisation in Playback Performance, meaning during benchmark test.
Because benchmark test push the system to its limit, high performance decoder like DXVA native can cause higher CPU utilisation with HEVC decoder which is a hybrid decoder, meaning it uses CPU and GPU, not ASIC (because there is no ASIC inside Haswell capable of HEVC decoding)
So, using DXVA native with a hybrid HEVC decoder in benchmark Playback Performance mode, causes more CPU utilisation than DXVA-CBD in the same test situation.
Is it clear now ?
You can test it on your own, to verify it.
ajp_anton
23rd February 2015, 14:07
Just to clarify, because I'm also seeing the contradiction.
Not knowing what "benchmark Playback Performance mode" is, going by its name I'm guessing that it runs it as fast as it can, and DXVAn causes higher CPU usage because it also achieves higher performance. But if it were that simple, you would've just said it...?
NikosD
23rd February 2015, 14:21
Yes, I'm talking about DXVA checker used in benchmark mode for playback and no it's not that simple because the previous version of Copy-Back before direct mode, had higher cpu utilisation on the same benchmark conditions than DXVA native.
P.J
23rd February 2015, 15:46
Use ffdshow with only raw audio processor installed, it'll run after LAV. You can do whatever you want to the sound then.
This is the way it SHOULD be done, and it's only not because Directshow is a PITA and players don't cooperate to make it simpler (or handle it all themselves), so everyone wants all the functionality built into a single filter. There are tons of audio processing filters out there, most non-free, but ffdshow has a lot of basic capabilities.
Thanks, but even WMP has this 3 options for Dolby Digital:
http://i.imgur.com/xknhMEX.jpg
http://i.imgur.com/M2zBh1V.png
vuquanghai
23rd February 2015, 18:21
Hi. I installed lav filter 0.63. How can i update to 0.64? Just download 0.64 setup file and install it or anything else?
One more question: Should i use lav splitter source or spliter?
Thank you guys!
Asmodian
23rd February 2015, 20:27
Thanks, but even WMP has this 3 options for Dolby Digital:
WMP is not be used as an example of how things should be done.
Just download 0.64 setup file and install it
Yes :)
One more question: Should i use lav splitter source or spliter?
What does an auto generated graph use?
DragonQ
24th February 2015, 01:21
I'm sure he wants the LFE mixed into the speakers. I would just disable LAV's mixer and add ffdshow to the chain to transform into custom formats.
Which is easily done by telling Windows you have full range front speakers and no subwoofer, or leaving it to your AVR, as I suggested.
foxyshadis
24th February 2015, 03:19
Which is easily done by telling Windows you have full range front speakers and no subwoofer, or leaving it to your AVR, as I suggested.
Huh, I didn't know the Windows mixer was that smart, I thought it just dropped the LFE. Nice!
Thanks, but even WMP has this 3 options for Dolby Digital:
And limiting it to Dolby Digital is a stupid artifact of putting it in the decoder, since it's just as useful for AAC, DTS, LPCM and every other format.
Try DC-DSP (http://www.dsp-worx.de/?n=4), it has a full-featured Compressor, and presets so you can have easy access (32-bit only right now).
LigH
24th February 2015, 08:49
And limiting it to Dolby Digital is a stupid artifact of putting it in the decoder, since it's just as useful for AAC, DTS, LPCM and every other format.
Well, at least Dolby Labs defined its behavior in specs. And DD audio streams may include metadata to support it. I don't remember other audio formats being prepared for that. So it may only be the kind of limiter or compressor the author of the player implemented.
bjd
25th February 2015, 12:34
v0.64.0 : Getting broken garbled playback on several 1440x1080 H265 (4:3 AR) files when using either DXVA mode on Nvidia GT640 - Cuvid and software fine. Will try and post a sample
bjd
26th February 2015, 13:31
Sample (http://www.filedropper.com/sample_9)
Seems to be only 1440x1080p on DXVA with an issue
nevcairiel
26th February 2015, 13:46
v0.64.0 : Getting broken garbled playback on several 1440x1080 H265 (4:3 AR) files when using either DXVA mode on Nvidia GT640 - Cuvid and software fine. Will try and post a sample
Seems like a NVIDIA bug to me. The hardware decoder on the GTX 960 handles it fine, so its only the hybrid decoder.
The DXVA2 spec says that surfaces should be aligned to 128 pixels, which is what my decoder does, but somehow that causes the NVIDIA Hybrid decoder to fail.
bjd
26th February 2015, 14:47
Seems like a NVIDIA bug to me. The hardware decoder on the GTX 960 handles it fine, so its only the hybrid decoder.
The DXVA2 spec says that surfaces should be aligned to 128 pixels, which is what my decoder does, but somehow that causes the NVIDIA Hybrid decoder to fail.
Thanks for the feedback, it is odd that Cuvid handles it ok if its a hybrid decoder issue.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.