LAV Filters - DirectShow Media Splitter and Decoders

[NikosD]

There is a new 17.3.1 driver but I haven't managed to test it yet, if anything changed for the better.

[clsid]

Originally Posted by Vasilich

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]

Originally Posted by clsid

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]

Originally Posted by Vasilich

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]

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]

Is there any parameter for silent installation with which I could only install the 64bit version?

[sneaker_ger]

Originally Posted by NikosD

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]

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]

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]

Originally Posted by NikosD

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)




MPC Video Decoder + Lav Splitter + MadVR (smooth)



Lav Video Decoder + Lav Splitter + EVR Sync/EVR Custom (stutters like crazy, dropp count)




Lav Video Decoder + Lav Splitter + MadVR (stutters like crazy, dropp count)



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]

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]

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]

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]

Originally Posted by nevcairiel

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]

Originally Posted by sneaker_ger

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]

I see, thx.

[CruNcher]

Originally Posted by nevcairiel

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]

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!MR6D8yPHF...QYM3fQqXW9gd4s

[sneaker_ger]

Again a sample muxed with old/broken DivX "Rovi" mkvmerge. That muxer was experimental and should never be used.

[NikosD]

But the previous similar file didn't have such issues with LAV filters.