View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
blaubart
24th July 2015, 14:31
Developers on vacations? Claiming to be sth. like real human beings? Impossible! Next time they want to marry and/or have children, stuff like that..?
Millions of addicts on the edge of meltdown, collapsing internet empires...
Developers! Believe me it's been too late for you to even think about an escape since a long time! So stop this nonsense now and back to your responsibility - right before your monitors, 24 h/d..!
Manni
24th July 2015, 15:25
Its not a priority for me, as I consider bitstreaming somewhat obsolete, especially now that we can decode DTS-HD without any external help.
Time constraints don't allow me to work on everything at the same time, so....
Hi Nevcairiel,
First of all, thanks for all your good work on LAV. Much appreciated!
Just wanted to stress that bitstreaming isn't obsolete, as it's the only way to play new formats like Atmos, DTS:X and Auro 3D correctly. They use metadata to handle the objects/extra channels and decoding Dolby TrueHD or DTS HD in the PC won't help, as we need more than 7.1 channels so unless there is some special hardware and the user isn't using an external AVR with these new sound format decoders, anything but bitstream is a no go.
It works fine at the moment, but I'm just raising this so you don't take your eyes off that ball :)
huhn
24th July 2015, 17:00
the number of dolby atmos discs is very low and the rest is not BD compatible.
http://www.dolby.com/us/en/experience/dolby-atmos/bluray-and-streaming.html
and even disc with dolby atmos are offend not using atmos outside of the US.
so he isn't over estimating this. the number of atmos and playback system is nearly not existing.
and BTW. he added a patch for FFMPEG to make atmos bit streaming working.
videonerd
24th July 2015, 19:37
No software can fix the fact that ASF is a terrible format. =p
As such, comparison to other containers is pointless.
No, the comparison is to other splitters that don't exhibit the issue e.g. vlc / default asf reader (shock, horror).
In your opinion, is this a bug in lav filters?
mindbomb
24th July 2015, 21:30
Typical HTPC setups a thing of the past huh? Wowww.
Well, since lav audio can decode dts-hd ma, dts, truehd, and dolby digital to pcm, and usb and hdmi support multichannel pcm, you generally don't need to bitstream except for multichannel audio over spdif and also for dolby atmos.
nevcairiel
24th July 2015, 21:48
It works fine at the moment, but I'm just raising this so you don't take your eyes off that ball :)
Bitstreaming isn't going away, but its just not a development priority for new features for me, is all.
apgood
25th July 2015, 03:43
the number of dolby atmos discs is very low and the rest is not BD compatible.
http://www.dolby.com/us/en/experience/dolby-atmos/bluray-and-streaming.html
and even disc with dolby atmos are offend not using atmos outside of the US.
so he isn't over estimating this. the number of atmos and playback system is nearly not existing.
and BTW. he added a patch for FFMPEG to make atmos bit streaming working.
DTS:X and Auto 3D are BD compatible there just aren't many of them so far (1 DTS:X and 2 Auro3D movies). Of course no one can really listen to the full DTS:X track on ex-machina until the relevant avr's are available
Manni
25th July 2015, 10:15
Bitstreaming isn't going away, but its just not a development priority for new features for me, is all.
Great, thanks for the confirmation :)
There is no need for new bitstream features as far as I can see, at least with current content. LAV bitstreams native Atmos (wrapped in Dolby TrueHD) and Auro 3D (wrapped in DTS:HD) tracks perfectly. Can't test DTS:X yet but we should find out by the end of the year when AVRs start to support it.
It's true that there isn't much native content at the moment, but I have 12 native Atmos titles and 1 Auro 3D movie, it would be a shame if we had to use PDVD to play these and lose all the goodness of LAV/MadVR/MPC-BE.
Again, thanks a lot for all your good work!
nevcairiel
26th July 2015, 10:22
what do you think about the new MPC-HC Internal Audio Renderer?
Any benefits using it instead of the default DirectSound?
This is unrelated to LAV, please discuss this in the MPC-HC thread.
James Freeman
26th July 2015, 10:25
This is unrelated to LAV, please discuss this in the MPC-HC thread.
Just a quick question, is it after LAV?
nevcairiel
26th July 2015, 10:34
A renderer is always after a decoder or splitter. It in no way replaces any part of LAV (well, maybe mixing, but that wasn't meant to really be a dominant feature in LAV anyway).
NikosD
26th July 2015, 19:00
What about all other decoders that support 10-bit, they also need to add work-arounds? Or they don't even try to support P010 because they know its broken - which isn't any better either.
Why doesn't Intel fix it again, just like NVIDIA did after they broke it briefly?
If they don't acknowledge their bugs then it's their fault, not nevcairiel's. You're barking up the wrong tree here.
I tried using MS MFT HEVC decoder with my Intel iGPU HD 4600 using DXVA Checker - Win 10 - Drivers v4256 and a 10 bit HEVC clip.
The result was P010 output during playback in window mode.
LAV gives me a black screen with the exact same test.
Tell me whose bug is this again ?
sneaker_ger
26th July 2015, 19:04
That only means MediaFoundation EVR does not have the same bug? Or how does DXVA checker use MS HEVC decoder?
NikosD
26th July 2015, 19:29
DXVA checker can use MFT and DS decoders.
It looks to me almost impossible for Intel to have a broken driver for P010 using DS but not broken using MFT.
Is that even possible ?
nevcairiel
26th July 2015, 19:30
DXVA checker can use MFT and DS decoders
And you are comparing DS and MF here, which are totally not the same thing. I have always theorized that MF may not have the same problem, but never had a way to test it. That has no relevance for DirectShow usage.
The underlying problem is a Microsoft problem in EVR, which may as well be DirectShow only. It cannot properly calculate the required buffer size for P010, resulting in too small buffers for the image. The front-end that would allocate these buffers is DirectShow-specific, so it is entirely possible that MF works, which I have said numerous times before.
The "bug" on Intels side is that they enabled P010 input in their driver, which triggers the bug in the EVR. The real bug is from Microsoft, not from Intel, but a behavior change in the Intel driver triggered the bug, just like it did when NVIDIA changed it some time ago - but NVIDIA disabled it again.
NikosD
26th July 2015, 20:14
That's good.
You learned something from Intel.
That it's Microsoft's bug and not Intel's bug that you were saying all that time.
Now that we all know what is going on, can you fix it ?
Because I don't have more time to spend between you blaming Intel and them denying that it is their fault.
Enough is enough for me.
nevcairiel
26th July 2015, 20:34
Now that we all know what is going on, can you fix it ?
I cannot fix Microsofts bug, no. EVR in DirectShow just doesn't handle P010 properly. I can possibly add a work-around, but i'll need to setup something on an Intel system, which may take some time.
Q-the-STORM
27th July 2015, 03:46
I have found a (so far) rare issue when decoding DTS-HD MA with LAV..
There seemed to be a new small audio glitch on one of my files, I write down notes on every media file that is corrupt in my collection, so I know it wasn't corrupt before.
Then the same thing happened again with another file, so I looked into it and the file isn't corrupt after all...
What happens is:
about 1-2 seconds get skipped, then after 1-2 seconds, there is a 1-2 second audio gap (not the same duration for both files, the skip/gap was longer for the other file).
kinda like the audio got pushed forward and needed a gap to get in sync again.
I use the current stable version of MPC-HC which contains LAV 0.65.0.9.
I also use SVP and reclock (WASAPI Exclusive), but the issue persists with both of them turned off (tried MPC-HC Audio Renderer instead of reclock)
also use madVR, but that shouldn't be a factor.
when I use ffdshow audio decoder there is no issue, also no issue when I use VLC for playback...
Same result with "Auto A/V Sync correction" turned on and off.
I demuxed dts-hd ma with eac3to and played it back, same issue.
Then I extracted the DTS Core with eac3to and played it back, now I didn't get the issue.
So this is probably a DTS-HD MA decoding problem.
Last time I played the file I didn't notice any issues, LAV didn't have dcadec back then, so this probably dcadec related.
But I decoded the audio with eac3to using both arcsoft and dcadec, both were fine, so this shouldn't be a dcadec problem by itself, which is why I'm contacting you and not dcadec's developer... Maybe something weird in LAVs implementation of it?
I uploaded 7 sec long mkv samples of both videos containing the issue.
hope you can reproduce and fix it.
http://www9.zippyshare.com/v/eKSjG5d2/file.html
http://www9.zippyshare.com/v/pOia4YI0/file.html
they are about 20MB each.
nevcairiel
27th July 2015, 09:24
I have found a (so far) rare issue when decoding DTS-HD MA with LAV..
Should hopefully be fixed, thanks for providing samples.
DTS can be a bit annoying to handle sometimes. :(
James Freeman
27th July 2015, 16:35
Just to nail this once and for all,
Should I use DXVA2 (copy-back) or CUVID?
Nev, I see you removed the CUVID from your signature, I guess there is no pride bearing this logo anymore...
nevcairiel
27th July 2015, 17:24
I should restructure these options and make it clear that QS and CUVID are not recommended, since with them you depend on an outside decoding library.
ashlar42
28th July 2015, 17:43
Strange behaviour to report.
I'm using 0.65.0 with madVR 0.88.21 on Kodi DSPlayer (but I tested this with MPC-HC too) and I have a strange thing happening with mkv files containing DTS-ES audio.
If I use Kodi's DVDPlayer (the internal player, basically), the file gets decoded correctly and the receiver gets multichannel PCM audio. If I use LAV, although internally LAV Audio, under status, reports multichannel audio being decoded and outputted (and the same is reported by Reclock if in use), the receiver just gets two channels stereo PCM.
If I bitstream, the receiver gets the correct DST-ES 6.1 discrete audio.
Edit: if I select "Expand 6.1 to 7.1" the receiver correctly gets multichannel PCM. Maybe my receiver (Yamaha Aventage RX-3010) can't accept a 6.1 PCM signal...
Edit 2: yeah... http://www.avsforum.com/forum/26-home-theater-computers/1446494-my-htpc-won-t-output-6-1-pcm.html#/forumsite/3207/topics/1446494
I am in fact using a GTX 660.
aufkrawall
30th July 2015, 14:17
Would it be possible with WDDM 2.0 to select any of the GPUs in the system for decoding?
nevcairiel
30th July 2015, 14:30
Would it be possible with WDDM 2.0 to select any of the GPUs in the system for decoding?
This has nothing to do with WDDM, its just a Direct3D thing.
It would already be possible today with D3D11 for decoding, but D3D11 decoding API is complicated and annoying.
oddball
30th July 2015, 14:36
I am unable to playback content using MPC-HC in Win10 (especially with MadVR which gives a direct3d error). After trying external filters I am unsure if LAV is involved at all. I am just posting here as well as the other threads to make sure though since MPC-BE works perfect in Win10 with MadVR.
EDIT: OK I tried LAV's standalone filters in MPC-BE and they work perfectly so I can only assume it is a MPC-HC issue.
aufkrawall
30th July 2015, 14:58
It would already be possible today with D3D11 for decoding, but D3D11 decoding API is complicated and annoying.
omg, Microsoft...
Thanks, nev!
mindbomb
30th July 2015, 16:18
Hi, I have a request. With a lot of older video cards, 1080p 60 fps h264 can't be decoded well in hardware. I wish I could specifically blacklist hardware decoding for these videos in lav video.
edit:
or actually, just a 60 fps option would more or less get the job done and be less disruptive to the current ui
duedel
31st July 2015, 10:43
HEVC hardware decoding with cuvid doesn't seem to work any longer on Win 10, avcodec is shown active.
DXVA2 is working fine.
Systems tested:
-Win 10, 64bit, GTX 750 Ti, latest Nvidia driver
-Win 10, 64bit, GT 330m, latest Nvidia driver
nevcairiel
31st July 2015, 10:52
DXVA is the preferred mode, so using that is not a bad thing. %)
If it stopped working on one OS, its likely NVIDIAs fault, anyway.
duedel
31st July 2015, 12:47
DXVA is the preferred mode, so using that is not a bad thing. %)
I noticed that my own test encode with the latest x265 build (http://builds.x265.eu/) works with DXVA2.
However, the Astra UHD Demo Channel (http://www.astra.de/18049106/ultra-hd) in HEVC in MPC-HC works neither with CUVID nor DXVA2.
I'd gladly provide samples if need be.
nevcairiel
31st July 2015, 13:12
Astra UHD broadcasts in 10-bit, which only a GTX 960 would support.
duedel
31st July 2015, 13:36
I see, thanks!
AndreaMG
3rd August 2015, 15:50
Hello Nev,
now that cuvid is forever and ever gone in WIN10 *_*, for us poor Nvidia owners, is there a way to get HW adaptive deinterlacing? Cheers :)
nevcairiel
3rd August 2015, 15:54
Use your video renderer to do deinterlacing.
AndreaMG
3rd August 2015, 16:07
Thank you Nev, so if I flag deinterlacing option in MadVR I get HW deinterlacing even if I've set DXVA2 (copy-back) in lav as video decoder? :confused:
nussman
3rd August 2015, 16:12
Yes of course.
Works with Software, DXVA native, and DXVA copyback if your video renderer support it.
AndreaMG
3rd August 2015, 16:20
Ah ok thanks @Nussman never tried it since I used the LAV built-in option :)
Aleksoid1978
5th August 2015, 14:11
Hi nevcairiel
In this sample (https://yadi.sk/i/eFmQ-MWBiHWR3) video stream about 50 seconds changed size, from 720x576 to 1920x1080. In DXVA native mode is seek beyond this place it's ok, DXVA decoder recommit and new resolution is apply in renderer and playback is good. But if start playback and don't touch - after ~50 seconds on Nvidia sometimes playback is good, sometimes is broken. On ATI - black screen. It's on vanilla EVR, on EVR Custom - almost always black screen.
Microsoft DTV-DVD Video decoder is good in this situation - on EVR/EVR Custom after 50 seconds little garbage and playback is continue.
nevcairiel
5th August 2015, 14:32
I tried just now on EVR Custom, and playback seem to always behave the exact same way as in DXVA-CB or Software mode. It lags a second, shows a bit garbage, and then plays fine.
I don't have access to any AMD system right now.
Aleksoid1978
5th August 2015, 23:24
You test in DXVA Native ??
P.S. Here (https://yadi.sk/d/-6jOYaMyiJ6Eb) 2 records - use LAV Video and use Microsoft DTV-DVD Video Decoder. Using EVR Custom in MPC-HC.
NikosD
6th August 2015, 06:20
Hi nevcairiel
In this sample (https://yadi.sk/i/eFmQ-MWBiHWR3) video stream about 50 seconds changed size, from 720x576 to 1920x1080. In DXVA native mode is seek beyond this place it's ok, DXVA decoder recommit and new resolution is apply in renderer and playback is good. But if start playback and don't touch - after ~50 seconds on Nvidia sometimes playback is good, sometimes is broken. On ATI - black screen. It's on vanilla EVR, on EVR Custom - almost always black screen.
I tried just now on EVR Custom, and playback seem to always behave the exact same way as in DXVA-CB or Software mode. It lags a second, shows a bit garbage, and then plays fine.
I don't have access to any AMD system right now.
Interesting clip.
Using MPC-HC x64 v1.7.9.137 with built-in LAV filters 0.65.35 and Win 10 x64 - iGPU 4600 - drivers 4256, the situation is this:
DXVA native: Both EVR/EVR-CP go to black screen after ~52 sec and stay black till the end.
DXVA copy-back: Both EVR/EVR-CP produce artifacts at ~52 sec but play fine after a few seconds (not immediately)
LAV QuickSync: Both EVR/EVR-CP produce artifacts at ~52 sec and stay with artifacts till the end. No clear image after 52 sec.
LAV SW: Both EVR/EVR-CP produce artifacts at ~52 sec but play fine after a few seconds - faster recovery than LAV CB but not immediately.
I didn't seek during playback.
Aleksoid1978
6th August 2015, 06:32
NikosD
Test also with Microsoft DTV-DVD Video Decoder.
NikosD
6th August 2015, 06:41
Both MS decoders (MFT/DS) play "fine", meaning they recover fast, in both modes (DXVA native and SW).
Aleksoid1978
6th August 2015, 07:37
I think MS Decoders know how do right reconnect to the renderer(or something similar) in DXVA mode :)
nevcairiel
10th August 2015, 14:47
now that cuvid is forever and ever gone in WIN10 *_*
FWIW, CUVID works just perfectly for me on Windows 10 with the 353.62 driver.
NikosD
10th August 2015, 19:26
I got an official answer today from Intel regarding P010 issue with 10 bit clips (H.264/H.265) and LAV filters.
"Our investigation concluded it was not technically feasible to work around the issue within the Intel graphics driver. Working around bugs found in 3rd party applications or OS are not always feasible or possible within our graphics driver. This is one of those cases."
XinHong
10th August 2015, 19:36
Hi Nev,
With videos from TV capture (and only from TV capture: live TV or recordings) I have macroblocs during fast motions in DXVA-native with EVR, EVR-Custom and madVR.
Everything is fine with Microsoft DTV-DVD Video Decoder.
I didn't had this problem with Windows 7 but I was with 15.28.23 drivers, now with Windows 10 it's 15.28.24.
This is a sample (1 min, 47 MB): http://www.mediafire.com/watch/v4o6ig9qhccvjko/M6HD-Capital.2015-08-09.20-58-012.mkv
My system:
Intel HD3000 (Sandy Bridge), drivers 15.28.24 (video driver 9.17.10.4229)
Windows 10 x64
Thanks
nevcairiel
10th August 2015, 19:39
Latest Intel drivers on Windows 10 are known to have many problems with DXVA.
NikosD
10th August 2015, 20:32
Hi Nev,
With videos from TV capture (and only from TV capture: live TV or recordings) I have macroblocs during fast motions in DXVA-native with EVR, EVR-Custom and madVR.
Everything is fine with Microsoft DTV-DVD Video Decoder.
Plays perfectly here with Haswell iGPU 4600 - Win 10 x64 - Latest Windows Update drivers 10.18.15.4256.
I tried DXVA native with EVR and EVR-CP.
There are only some glitches at the very first few frames, but these are known occasional small issues with LAV Video decoder from the past.
MS DS/MFT is perfect once again, even at the very beginning of the clip.
I'll try with my Sandy HD 2000 on Windows 10 on Saturday.
If you haven't already done it, I would recommend a clean install of Win 10 - as always with any new OS.
Latest Intel drivers on Windows 10 are known to have many problems with DXVA.
MS DS decoder is using the exact same decoder device like LAV.
If MS plays fine, why LAV shouldn't ?
From the problems being mentioned in Intel forums regarding DXVA, I have none.
nevcairiel
10th August 2015, 20:37
MS DS decoder is using the exact same decoder device like LAV.
If MS plays fine, why LAV shouldn't ?
From the problems being mentioned in Intel forums regarding DXVA, I have none.
Bugs are not necessarily predictable (or logical).
From what I hear about the Intel DXVA bugs reported on their forums, it can play fine for a bit and then randomly and suddenly start turning into a pixelated mess.
If it worked on a previous OS, and then broke after the upgrade, its a good bet that its the driver for Windows 10, at least triggered by some conditions, considering he isn't the only one reporting such issues.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.