View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
NikosD
7th March 2017, 08:59
There is a new 17.3.1 driver but I haven't managed to test it yet, if anything changed for the better.
clsid
7th March 2017, 15:09
Is it planned to implement such fallback? is it possible for audio decoder to get such info?It is planned. But you simply shouldn't enable it if your hardware doesn't support it. So solution is simple, disable it and everything will work.
Vasilich
7th March 2017, 20:10
But you simply shouldn't enable it if your hardware doesn't support it. So solution is simple, disable it and everything will work.
I did it already long time ago. But it is not always possible (or really time-consumnig) to find out which formats are supported by hardware, e.g. if you try to help people, who post their setups on forums, making sometimes wrong assumption that their hardware should support some specific formats they have problems with.
el Filou
8th March 2017, 15:08
I did it already long time ago. But it is not always possible (or really time-consumnig) to find out which formats are supported by hardware, e.g. if you try to help people, who post their setups on forums, making sometimes wrong assumption that their hardware should support some specific formats they have problems with.
With HDMI, if you want to be sure you can use Monitor Asset Manager from EnTech Taiwan: http://www.entechtaiwan.com/util/moninfo.shtm
It shows in detail which audio formats are supported by your HDMI sink, e.g. on my AVR:
CE audio data (formats supported)
LPCM 8-channel, 16/20/24 bit depths at 32/44/48/88/96/176/192 kHz
DTS 6-channel, 1536k max. bit rate at 44/48/88/96 kHz
AC-3 6-channel, 640k max. bit rate at 32/44/48 kHz
DTS-HD 8-channel, 16-bit at 44/48/88/96/176/192 kHz
DD+ 8-channel at 44/48 kHz
DVD-A 6-channel at 44/48/88/96/176/192 kHz
DVD-A 8-channel at 44/48/88/96 kHz
It is more useful than Windows' Sound Control Panel applet which on my system doesn't even list all the codecs.
NikosD
10th March 2017, 09:24
The 4K HEVC 10bit clip below, has decoding problems with LAV Video latest version in both SW decoding and HW decoding during normal playback and after seeking.
The same clip plays fine using PotPlayer SW & HW decoding, during playback and after seeking.
https://www.sendspace.com/file/sdd6wk
Octo-puss
10th March 2017, 10:38
Is there any parameter for silent installation with which I could only install the 64bit version?
sneaker_ger
10th March 2017, 11:44
The 4K HEVC 10bit clip below, has decoding problems with LAV Video latest version in both SW decoding and HW decoding during normal playback and after seeking.
The same clip plays fine using PotPlayer SW & HW decoding, during playback and after seeking.
https://www.sendspace.com/file/sdd6wk
What problems? It seems to work fine here. Are you using LAV Splitter? The clip uses open-gop in mp4 which some muxers and demuxers seem to have problems with. I recommend to turn off open-gop for mp4 container.
NikosD
10th March 2017, 12:09
The framerate drops significantly during playback and after seeking and it's clearly visible like a small stuttering.
You have to decode it in a player that can handle it flawlessly to see the difference.
davidsama
10th March 2017, 19:15
That 4K HEVC 10bit clip dropped 12 frames and had a clearly visible stuttering in Mpc-hc 1.7.11.13 using lav filters 0.69.0.4.
CruNcher
11th March 2017, 00:43
The framerate drops significantly during playback and after seeking and it's clearly visible like a small stuttering.
You have to decode it in a player that can handle it flawlessly to see the difference.
Yeah its strange at the limit overall @ P010 MPC Video Decoder with MadVR and Lav splitter dropps less frames, with EVR Custom/Sync Lav Video is even strangely jumping between detected framerates sometimes it shows 60 FPS instead of 25 FPS and is only Decoding with 15 FPS Graph result looks weird.
Almost same behavior as with the FTC needed but FTC doesn't help at all this time.
MPC Video Decoder + Lav Splitter +EVR Sync/EVR Custom (smooth)
http://i1.sendpic.org/t/sI/sIPHF4YFjDvB93nOVNiCG8ertId.jpg (http://sendpic.org/view/1/i/5wkQTGktmf1kJfs9OOWjhdTKhvZ.png)
http://i1.sendpic.org/t/xD/xDwc7L43mdwW4l2HVQ9G5SDrblq.jpg (http://sendpic.org/view/1/i/hzE9H9vhsZ4xntxCHvcgvUe7T6R.png)
MPC Video Decoder + Lav Splitter + MadVR (smooth)
http://i1.sendpic.org/t/zV/zVeAfOiRwBLnbjRHbYsrgxelj1H.jpg (http://sendpic.org/view/1/i/ipE1dE2g4zXG5nf5E8AIghFxv2I.png)
Lav Video Decoder + Lav Splitter + EVR Sync/EVR Custom (stutters like crazy, dropp count)
http://i1.sendpic.org/t/pb/pblBg5lmFXHR7Vm6qQpopvol0Cl.jpg (http://sendpic.org/view/1/i/rj6UViM53EUTFGl3cE7VQJQRMDM.png)
http://i1.sendpic.org/t/aB/aB6YmqFQhtns9yP0Chj8e423Yll.jpg (http://sendpic.org/view/1/i/5RrcD11327Wm65zQF7P6m4yG4lC.png)
Lav Video Decoder + Lav Splitter + MadVR (stutters like crazy, dropp count)
http://i1.sendpic.org/t/cy/cy54sqZkqA6EPOQdRT7uRBULeo.jpg (http://sendpic.org/view/1/i/5FjwdpCkyMclw8Z5jOB8PML0rBp.png)
I really wonder what goes on here that the Match is so crazy off with Lav Video and Hysteresis in the end so heavy and half of the frames get dropped, instead of 0.50 seconds 1 frame every second.
nevcairiel
11th March 2017, 10:18
There is no performance issue with that clip, but a timestamp issue. I have not figured out yet if the file is just broken or something screws up in the middle.
Other decoders often ignore input timestamps to some degree and create their own new ones, which can hide such issues but in other situations could potentially cause other issues instead (like sync problems).
Some basic checking shows that the decoder definitely receives wrong timestamps from the source. If the splitter screws something up or the file has "issues" is yet to be determined.
CruNcher
11th March 2017, 10:40
yeah it was pretty clear seeing the jumping framerate detection it couldn't really be a Performance issue but more container or bitstream parsing related.
Also performance mostly unlikely as MPC Video Decoder and Lav Video buildup on the same Decoder core anyways and as you said the differences are more internal tuning to the Playback chain (stability) and overall behavior with every internal part.
nevcairiel
11th March 2017, 11:17
Turns out the file is kind of broken, it has no CTTS box which is used to map the DTS to PTS timestamps, which for proper HEVC would be required to generate proper timestamps from mp4.
I applied a work-around I already had in place for H264, so when you use LAV Splitter + LAV Video, it should work now. With other source filters or other decoders, there are no such guarantees.
A long term task for me is to make LAV Video automatically detect if DTS timestamps are provided and somehow make that work (right now it relies on LAV Splitter to tell is that), but its a weird heuristic with some problems, so I'm not too eager to try to do this just to fix some broken files.
sneaker_ger
11th March 2017, 12:02
Turns out the file is kind of broken, it has no CTTS box which is used to map the DTS to PTS timestamps, which for proper HEVC would be required to generate proper timestamps from mp4.
But only when b frames are used (like in this sample), right? Or is it always required for HEVC in mp4?
nevcairiel
11th March 2017, 12:26
But only when b frames are used (like in this sample), right? Or is it always required for HEVC in mp4?
Without b frames it's probably fine without.
sneaker_ger
11th March 2017, 12:52
I see, thx.
CruNcher
11th March 2017, 13:43
Turns out the file is kind of broken, it has no CTTS box which is used to map the DTS to PTS timestamps, which for proper HEVC would be required to generate proper timestamps from mp4.
I applied a work-around I already had in place for H264, so when you use LAV Splitter + LAV Video, it should work now. With other source filters or other decoders, there are no such guarantees.
A long term task for me is to make LAV Video automatically detect if DTS timestamps are provided and somehow make that work (right now it relies on LAV Splitter to tell is that), but its a weird heuristic with some problems, so I'm not too eager to try to do this just to fix some broken files.
Understandable though i sometimes wonder if it's good at all to fix or workaround such broken streams without indicating and making those workarounds visible/selectable in the GUI as chose able paths, as Dedicated Hardware wont be so forgiving at all to whoever creates such out of specs files ;)
And a failing file is a good indicator to someone, hey you do something wrong ;)
So every parsing workaround that is Hardware Critical in some way should be rather choseable like a strict spec working mode which more imitates how dedicated hardware would react to such a stream.
Also i wonder what for regressions such a workaround could cause that without such mode switching abilities would be rather rushing through.
Currently Lav Filter only expose the VC-1 timestamp workarounds inside Lav Splitter to the outside but pretty much non of the rest that's going on in Lav Splitter and pretty much 0 of what is behind the scenes done inside Lav Video.
NikosD
12th March 2017, 14:27
Similar case with the previous file, only worst.
You can't even seek, even using latest LAV filters 0.69.08 (splitter + decoder)
HEVC 4K 8bit:
https://mega.nz/#!5lEhEKLA!MR6D8yPHFZRxdV9uECh3iQ3AYDqpZQYM3fQqXW9gd4s
sneaker_ger
12th March 2017, 14:32
Again a sample muxed with old/broken DivX "Rovi" mkvmerge. That muxer was experimental and should never be used.
NikosD
12th March 2017, 14:34
But the previous similar file didn't have such issues with LAV filters.
sneaker_ger
12th March 2017, 14:38
No I frames are marked as IDR or CRA in the bitstream (except the very first frame). Bad encode.
CruNcher
12th March 2017, 15:23
Again a sample muxed with old/broken DivX "Rovi" mkvmerge. That muxer was experimental and should never be used.
Old you mean used in their Divx Suite for Production or Beta ?, because their own released samples never had issues.
Like
fitness-trailer-8000.mkv
hollywood-makeover-8000.mkv
KAZU_(SUBTITLES)_4K23.98p_HEVC_10Mbits.mkv
SHANE_ONEIL 4K24p_HEVC_10Mbits.mkv
Writing application : DivXMKVMux 4.0.10.1893
Writing library : libDivXMediaFormat 4.0.0.0578
Writing application : DivXMKVMux 4.0.10.2513
Writing library : libDivXMediaFormat 4.0.0.0578
sneaker_ger
12th March 2017, 15:32
I don't know about DivXMKVMux. If in doubt: avoid it. Especially if it's older than HEVC support in official mkvmerge.
CruNcher
12th March 2017, 15:42
it looks like though some used it for Production and those broken streams are circulating now or some strange de/muxing operation created those non interoperable files now
Similar case with the previous file, only worst.
You can't even seek, even using latest LAV filters 0.69.08 (splitter + decoder)
HEVC 4K 8bit:
https://mega.nz/#!5lEhEKLA!MR6D8yPHFZRxdV9uECh3iQ3AYDqpZQYM3fQqXW9gd4s
Seeking though works somewhat here just takes ages also because the 4 cores are under practical full load and even the MadVR overhead seems already to much ;)
Runs a bit better without MadVR overhead but it's at the Edge of the Cores with some Latency issues here and there though not using latest lav decoder not sure if any improvements where done on the CPU decoding part it seems partly still underutilized.
Though threading efficiency is problematic in this lav decoder and 99% is at such a critical edge there are no words for it how critical without efficient threading ;).
That tractor scene kills it for some seconds pretty much at its motion peak (which most probably is also the complexity peak of the whole encode) ;)
http://i1.sendpic.org/t/hA/hA5bD6NZ9MgS6stZeuetPv65j5u.jpg (http://sendpic.org/view/1/i/6Kw5qrkg0SznVGMQVmERWng4d4r.png)
And that is also pretty much DivX Profile target here ;)
Wonder if i can lower the complexity with Nvidias Encoder in Realtime without hurting it much, especially in those high motion scenes they are anyway semi perceptible overall already :)
PS: Either i imagine things or some frames look very familiar from somwhere.
Hmm
That Cowboy, Rollercoster and Skateboard scene trigger something.
groen
13th March 2017, 14:00
You should disable passthrough for E-AC3. Then LAV Audio will work fine. Your receiver (or sound driver) does not support E-AC3 bitstreaming. LAV Audio decoder does not (yet) have a fallback to normal decoding when passthrough fails.
Thanks for the reply.
The reason this was not working was it requires hdmi cable rather than optical cable to passthrough.
It works fine over HDMI. Probably because of the bitrate requirements.
Sorry to bother.
LigH
14th March 2017, 09:01
I do remember that S/P-DIF or TOS-Link were limited to bitrates of 48 kHz stereo (1536 kbps). No chance to use it for 6-channel PCM. Some HD audio formats may surpass this as well.
clsid
14th March 2017, 16:41
AviSynth scripts crash with AviSynthPlus r1576. Got broken between 0.68.1-25-82c5743 and 0.68.1-33-4fde984
nevcairiel
14th March 2017, 18:15
LAV now requires AviSynth 2.6, and 2.5 is no longer supported, and I cannot comment on AVS+. If it doesn't match AVS 2.6 behavior/features, then its not supported.
clsid
14th March 2017, 22:58
The most recent changes in FFmpeg regarding AVS are for AVS+ specific (extra) colorspaces. So it is supposed to work with AVS+ as well.
nevcairiel
14th March 2017, 23:02
LAV just uses ffmpeg, so if it doesn't work then it doesn't work. There is no AVS specific code in LAV itself.
Feel free to test with ffmpeg itself to see if it works there.
djesteban
15th March 2017, 04:40
AviSynth scripts crash with AviSynthPlus r1576. Got broken between 0.68.1-25-82c5743 and 0.68.1-33-4fde984
Thanks for reporting it here clsid! I was about to post this too!
I will try to test it with the latest release of ffmpeg and post the result here.
djesteban
15th March 2017, 05:11
Hahaha! omg here's the message I got when trying to play my avs script in ffplay (comes with ffmpeg).
AviSynth version is too old. Please upgrade to either AviSynth 2.6 >= RC1 or AviSynth+ >= r1718.
So, i went to the Avisynth+ website thinking maybe I didn't click the right thing earlier this week when I upgraded my version... and it still downloads build r1576.....
So I checked here on Doom9 and found this post (https://forum.doom9.org/showthread.php?p=1643908#post1643908) that was updated last July with a fork of the project hosted on github.
Newest version there is r2440
There is no installer, but you can use the installer from r2294 (http://www.dropbox.com/s/f0a55fixmvagroa/AviSynth%2B%20r2294.7z?dl=0) and overwrite the files manually after.
Will then work with ffmpeg , lav and mpc-hc :)
LigH
15th March 2017, 08:40
Do not go to the AviSynth+ website to download (it may still link the "ancient" non-MT release). Instead, check the forum thread (https://forum.doom9.org/showthread.php?t=168856) for MT releases by pinterf, like Avisynth+ r2440-MT (https://forum.doom9.org/showthread.php?p=1800445#post1800445), or his releases on github (https://github.com/pinterf/AviSynthPlus/releases).
Q-the-STORM
16th March 2017, 02:34
Is there a way to get the correct HDR infoframe from a file with LAV?
I use MPC-HC + LAV + madVR and a HDFury integral, so I can use HDR passthrough mode with madVR, but I still need the infoframe from the file for the Integral.
clsid
16th March 2017, 03:03
HDR passthrough mode in MadVR has not been implemented yet. It doesn't do anything right now...
Q-the-STORM
16th March 2017, 04:55
HDR passthrough mode in MadVR has not been implemented yet. It doesn't do anything right now...
the passthrough of HDR metadata via infoframe has not been implemented. But, I don't need it if I use the Integral to inject the Infoframe myself. I just need the infoframe from the file so I can inject it.
sneaker_ger
16th March 2017, 12:17
Use MediaInfo to read HDR metadata from HEVC or MkvInfo to read from mkv/webm.
CruNcher
16th March 2017, 12:56
or
https://hdr.avtop.com/hdr_solutions_avtop
EpsilonX
18th March 2017, 02:01
@nevcairiel
Hi nev, I ran into a tiny problem with recent LAV, the last working revision was 0.68.1-46.
Since then, some videos became a stuttery mess, It can only be played normally if I disable DXVA.
Here's a short sample...
http://mir.cr/6KNZUMGL
PS:
Pay no attention to the video source :devil:
NikosD
18th March 2017, 05:52
@nevcairiel
Hi nev, I ran into a tiny problem with recent LAV, the last working revision was 0.68.1-46.
Since then, some videos became a stuttery mess, It can only be played normally if I disable DXVA.
Here's a short sample...
http://mir.cr/6KNZUMGL
PS:
Pay no attention to the video source :devil:
Can you upload it to sendspace.com or somewhere else that it doesn't need registration like your host ?
EpsilonX
18th March 2017, 07:31
Can you upload it to sendspace.com or somewhere else that it doesn't need registration like your host ?
What registration..? :rolleyes:
just click on "Click Here", I upload it to 4 host...
No registration needed...
NikosD
18th March 2017, 07:51
What registration..? :rolleyes:
just click on "Click Here", I upload it to 4 host...
No registration needed...
Right, I was blind.
Dropjiffy is OK to download.
That H.264 SD clip in MP4 container plays fine with CPU decoding, but using DXVA2 of LAV video has issues.
But on the other hand, PotPlayer can decode it fine in both SW&HW decoding.
So, the file seems not broken, maybe LAV splitter's issue ?
EpsilonX
18th March 2017, 09:07
That H.264 SD clip in MP4 container plays fine with CPU decoding, but using DXVA2 of LAV video has issues.
But on the other hand, PotPlayer can decode it fine in both SW&HW decoding.
So, the file seems not broken, maybe LAV splitter's issue ?
Exactly, only DXVA which is affected...
I'm using ZoomPlayer + LAV + MadVR...
Maybe this commit..?
https://github.com/Nevcairiel/LAVFilters/commit/6a03ce4a405e7fad4231201433df12099ff90bb4
nevcairiel
18th March 2017, 22:50
It was indeed caused by that commit, it is however technically not a "bug", but a limitation resulting from how the hardware decoder works (ie. it runs out of surfaces due to the combination of 16 ref frames and strict mode).
In any case, I'll make it disable strict mode when hwaccel is used, it may result in losing one frame or so at the start of a badly cut stream, but not double the requirement of surfaces, which can even result in failure.
NikosD
23rd March 2017, 18:13
It was indeed caused by that commit, it is however technically not a "bug", but a limitation resulting from how the hardware decoder works (ie. it runs out of surfaces due to the combination of 16 ref frames and strict mode).
In any case, I'll make it disable strict mode when hwaccel is used, it may result in losing one frame or so at the start of a badly cut stream, but not double the requirement of surfaces, which can even result in failure.
There is a HUGE problem with every HEVC clip I tried using latest nightly 0.69.14 and HW acceleration with my Haswell Core i3-4170.
I tried both DXVA native and copy-back.
Whenever it starts decoding in the middle of the file, it stucks there and can't go on.
You have to set the player to remember last position of playback, move forward the file to a random position, then close the player and reopen it.
It stucks there, can't decode a single frame!
LigH
23rd March 2017, 19:09
I bet if you disable HW acceleration, so the whole decoding is done on your CPU with LAV Filters' decoding software, this won't happen? ... So you can't blame LAV Filters for your hardware failure?
NikosD
23rd March 2017, 19:58
Have you done any tests using LAV latest nightly after all those changes in HW decoding of the last commits and everything is working fine with HEVC ?
Because on my exact same HW, the HW decoding of H.264 works fine.
So, I bet you have no idea what I'm talking about and what are you talking about.
LigH
23rd March 2017, 20:09
OK, you will be right here. :o
CruNcher
23rd March 2017, 20:59
Have you done any tests using LAV latest nightly after all those changes in HW decoding of the last commits and everything is working fine with HEVC ?
Because on my exact same HW, the HW decoding of H.264 works fine.
So, I bet you have no idea what I'm talking about and what are you talking about.
Hm could be the same issue nev spoke about the same way this ref 16 sample fails with it on Nvidias Decoder, it just freezes.
Cyberlink DXVA
Potplayer DXVA
Mainconcept DXVA
CoreAVC 3.0.1 DXVA
MPC DXVA
Microsoft DTV-DVD DXVA (Mainconcept)
dont fail on this sample like Lav DXVA does currently freeze, some seem to fallback to CPU though ;)
oha in case of CoreAVC DXVA it seems to be rather completely broken by now (no bitstream works anymore it's completely dead and falling back to CPU for anything, CUVID decoding is still working also with this sample but DXVA seems pretty dead with CoreAVC it totally stooped working).
nevcairiel
23rd March 2017, 23:54
There is a HUGE problem with every HEVC clip I tried using latest nightly 0.69.14 and HW acceleration with my Haswell Core i3-4170.
I tried both DXVA native and copy-back.
Whenever it starts decoding in the middle of the file, it stucks there and can't go on.
You have to set the player to remember last position of playback, move forward the file to a random position, then close the player and reopen it.
It stucks there, can't decode a single frame!
Works fine for me on every clip I tried.
Hm could be the same issue nev spoke about the same way this ref 16 sample fails with it on Nvidias Decoder, it just freezes.
16 references is invalid for HEVC, and the 16ref H.264 sample above plays just fine with the latest version.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.