LAV Filters - DirectShow Media Splitter and Decoders

[midiboy]

Check out the AVR settings. Perhaps, its set to pass sound to TV, and since TV doesn't supports HD sound... Also check Windows sound properties for HDMI audio. Do you see HD formats there?

Hey Qaq!

I already checked, the receiver is set to AMP not TV. I can see all supported formats in the HDMI settings dialog in Windows, as you can see, it should support all HD formats:

http://i.imgur.com/sVxpP5s.png

[bouwew]

Why not use AC3Filter (lite)? It can perform all that is needed: LFE filtering and 10dB amplification.
I use it in combination with LAV for DTS HD-MA decoding since my receiver can only do upto DTS. I'm streaming 6-channel pcm to my receiver when looking at a movie with DTS HD-MA audio.
If you want, I can post my AC3Filter-settings.

Any news on the Low-Pass Filter decision? I was watching the Interstellar blu-ray (DTS-HD MA track, newest nightly, no DLL), and their is distinct audio distortion on high-bass parts (wormhole, waves), distortion that definitely shouldn't be there (Audio switcher, only LFE ticked). As far as I know, even with the Dolby Home Theatre v4 black-box, there is no low-pass filtering in the entire audio chain. For a standard USB DAC, motherboard audio or sound card, there won't be low-pass filtering, which means distortion. Should this be done at the individual decoder level, or globally by LAV? It would keep LAV simple if the decoder was responsible for low-pass filtering, ending concerns about double-filtering. Especially considering that many of the codecs people use are filtered at the encoding stage (AC3, standard DTS), and its only a few popular codecs that need filtering (DTS-HD, TrueHD). And conveniently, one of those decoders is still in active development, the other implemented by FFmpeg (I think) which could still be patched.

Star Trek (TrueHD 5.1) also has distortion in the LFE channel.

[nevcairiel]

If you use a receiver, you should not perform the 10dB LFE attenuation in software. Instead, do it with the receiver (if it doesn't do it already, anyway!)
Also, most receivers have a LFE Low-Pass option, too.

[bouwew]

Update: just checked the settings of my receiver, turns out they were reset somehow, I need to retest to make sure my statement below is still correct.

In my case, when sending 6-channel PCM, that is not the case.
When I'm bitstreaming, via HDMI, DTS to my receiver, and when I'm sending decoded DTS via 6-channel PCM to my receiver, I can hear clearly that the volume of the LFE frequencies is lower in the second case.

Btw, my spreaker setup is a 5.0 setup. 3 small speakers: center, surround left and right, 2 full range speakers: left and right.

[bouwew]

Update 2:
I have setup my receiver (Onkyo TX-SR804) correctly now: disabled the LFE and set the front speakers to FULL BAND. I noticed the "LFP of LFE" option has not disappeared so I assume the LPF is still active. Will test later.
Now, when retesting the two scenario's described above, I can hear a distinct difference in Bass-level. With a tick in the LAV audio filter DTS-box the Bass sounds louder than without this tick. Apparently, in the 6-channel PCM case the Bass gets redirected to the fronts but not at the correct level. When I then enable AC3Filter and enable the option that redirects the LFE channel to the fronts, the Bass seems to be at the same level. But this could give 6dB amplification, a difference of 4dB is less easy to hear than 10dB.

Nev, can I request that you add a 5.0-option to the Output Speaker Configurations? In that case I can omit AC3Filter and just use LAV mixing to get the Bass to the right level :)

[ryrynz]

Buy a receiver that syncs faster to the audio stream. Nothing can be done about slow hardware.

Found the culprit, default Directsound out. MPC-BE's audio renderer is a lot faster. Looks like MPC-HC really could use that new audio renderer released asap.

[bouwew]

Nev, another question/issue:
Since my receiver can decode DTS at max/best, I want libdcadec to decode the DTS HD-MA and TrueHD audio. In LAV audio filter I have unticked the DTS-HD and TrueHD boxes to match my receiver capabilities.
Now, what is happening when I play a movie with DTS HD audio, MPC-HC with LAV filters outputs the DTS core to my receiver. The only way to get DTS-HD decoded correctly (by libdcade) is by unticking the DTS-box in LAV audio. Is there any way to automatically achieve that DTS audio is bitstreamed to the receiver and DTS-HA audio is decoded by MPC-HC/LAV/libdcadec and then streamed as 6-channel PCM?

[nevcairiel]

This is not possible, and its not an option I plan to offer.

[bouwew]

This is not possible, and its not an option I plan to offer.

This is regarding the DTS / DTS-HD question/issue? No problem, I can work around that :)
Or the 5.0 configuration request? That would be nice to have.

[SeeMoreDigital]

Hi Nev,

I can't remember if it's been asked before, but would it be possible to add a multi-channel PCM 'bitstreaming/pass-through' option to LAV Audio Decoder?

http://i62.tinypic.com/oqca4g.png

The Blu-ray audio HFPA disc format is including multi-channel PCM (anything up-to 192KHz/24-bit) on some of their disc releases.

Cheers

[nevcairiel]

PCM is PCM, you don't need any bitstreaming for it, and the IEC 60958 or IEC 61937 spec also doesn't define anything for it.

[Helios61]

PCM is PCM, you don't need any bitstreaming for it, and the IEC 60958 or IEC 61937 spec also doesn't define anything for it.

Does that mean, that PCM isn't processed by Windows Mixxer?

[andyvt]

Does that mean, that PCM isn't processed by Windows Mixxer?

To bypass the mixer you need to use a WASAPI renderer. It's not a function of the decoder.

[SeeMoreDigital]

PCM is PCM, you don't need any bitstreaming for it, and the IEC 60958 or IEC 61937 spec also doesn't define anything for it.It would be most useful to have an easy option to pass multi-channel PCM audio via HDMI. Without having to fiddle about with your software media players settings...

[mindbomb]

It would be most useful to have an easy option to pass multi-channel PCM audio via HDMI. Without having to fiddle about with your software media players settings...

The output format settings on the right are the settings that control pcm output from lav audio. I think what you want is a different audio renderer.

[Fantasy]

hello,
I encode video in webm format with high bitdepth (10 bit).
Then I play it with MPC-HC and LAV Video Decoder 0.64.0 but it seems that MPC-HC with LAV Video Decoder can't decoded webm format with high bitdepth.
Can you add support for decoding webm format with high bitdepth please?

[P.J]

mkvtoolnix
MMG>Global> split based on fields numbers.
It refuses to work due to so many artifacts

As you talking about recorded mpeg - can split it's as binary file, use dgsplit, http://neuron2.net/dgsplit/dgsplit12.zip
After splitting, the problem disappears and I can use the seekbar :confused:

[Aleksoid1978]

After splitting, the problem disappears and I can use the seekbar :confused:

Upload original file :)

[Arm3nian]

It would be most useful to have an easy option to pass multi-channel PCM audio via HDMI. Without having to fiddle about with your software media players settings...

Multichannel pcm is already the default, through windows or software. Everything is decoded and output in pcm unless you choose to bitstream. If you want wasapi for pcm output then tick the box in the renderer. Wasapi is useless and often creates problems for bitstream, since the output is already untouched.

[NikosD]

Hello.

Using LAV Video x64 0.64.38 I have visual glitches with almost every .ts HEVC file 8bit and 10bit using SW decoder, DXVA Copy-back and DXVA native.
Looks like a LAV splitter problem with .ts files.

The glitches appear after seeking and sometimes at the beginning of the file.

[nevcairiel]

Glitches after random access in TS files are normal, the TS format was built for streaming and broadcasting, not with seeking as its primary purpose.
The format does not include any information where a "clean" seek point is, so without that information, the decoder has to recover from whichever position you seeked to, which can and will result in a few broken frames after seek (and/or at the start of the file, if the file was cut badly).

[NikosD]

Thanks.

The reason I report that now, is because I don't remember those glitches with previous version of LAV.
It seemed to me that something changed relatively recently.

[P.J]

Glitches after random access in TS files are normal, the TS format was built for streaming and broadcasting, not with seeking as its primary purpose.
The format does not include any information where a "clean" seek point is, so without that information, the decoder has to recover from whichever position you seeked to, which can and will result in a few broken frames after seek (and/or at the start of the file, if the file was cut badly).

Yes, this problem looks even much worse in DXVA2 copy-back.
No need to seek, just a bad frame causes it while playing :(

http://phota.me/1xEK.png

[madshi]

In h264 there are recovery point SEIs that allow to find out which frame is "safe" to seek to. Are these SEIs gone in h265? If all else fails, shouldn't it be possible to analyze the bitstream to search for a frame which has no references to any past frames? Such a frame should be safe to seek to, shouldn't it? I think it should be technically possible to find a safe seek position, even if it may be more difficult compared to h264 (I don't know).

[nevcairiel]

Of course its possible somehow, but its super complex, so I'm not going to bother. Maybe someone will do this for ffmpeg.
FWIW, for H264 this is not implemented in the demuxer either, the decoder just discards any frames that are not "clean".

Asking a demuxer to know about a long and ever growing list of video formats and be able to identify keyframes for all of them is just madness, so it will never do that. It will act on information inside the container metadata, and not try to interpret the video data inside it at all.
The decoder can handle all the video stuff then, including dropping any corrupted frames if this is implemented for the codec in question. It just isn't for HEVC, maybe some day someone will do it.

Ideally, videos should just come in containers that have key-frame info, like MP4 or MKV. Commercially, TS is only really used for broadcasts (and Blu-ray, but Blu-ray has extra metadata for clean seek points), and people are generally just too lazy to remux the videos after recording a broadcast, so shrug.

[Aleksoid1978]

Of course its possible somehow, but its super complex, so I'm not going to bother. Maybe someone will do this for ffmpeg.
FWIW, for H264 this is not implemented in the demuxer either, the decoder just discards any frames that are not "clean".

Asking a demuxer to know about a long and ever growing list of video formats and be able to identify keyframes for all of them is just madness, so it will never do that. It will act on information inside the container metadata, and not try to interpret the video data inside it at all.
The decoder can handle all the video stuff then, including dropping any corrupted frames if this is implemented for the codec in question. It just isn't for HEVC, maybe some day someone will do it.

Ideally, videos should just come in containers that have key-frame info, like MP4 or MKV. Commercially, TS is only really used for broadcasts (and Blu-ray, but Blu-ray has extra metadata for clean seek points), and people are generally just too lazy to remux the videos after recording a broadcast, so shrug.

About H265(HEVC) - ffmpeg support detect and set key-frame marker. So - you can use it's after seeking as well as for MPEG2/VC1 in decoder. I use it in MPC-BE - and no artefact after seeking :)

[nevcairiel]

HEVC is much more complex than that. It wouldn't work reliably for H264, and it won't work reliably for HEVC.
There can easily be streams without key-frames, or "key" frames that are not enough to avoid artifacts - just like in H264. Its a complex codec, so I rather not try to do some half-baked solution. Who really cares about a few frames of artifacts, if the alternative is a black screen and not seeing anything?

[SeeMoreDigital]

Multichannel pcm is already the default, through windows or software. Everything is decoded and output in pcm unless you choose to bitstream. If you want wasapi for pcm output then tick the box in the renderer. Wasapi is useless and often creates problems for bitstream, since the output is already untouched.
Well, try as I might, I'm unable to figure out how to reliably pass multi-channel PCM audio via HDMI to my surround sound amplifier using LAV injunction with MPC-BE.

I currently have some 6Ch and 8Ch PCM samples placed within the .m2ts container, which engages LAV Audio Decoder just fine, but my surround sound amplifier is only detecting 2 channels.

I'm sure I've had this working in the past :eek:

[madshi]

Of course its possible somehow, but its super complex, so I'm not going to bother. Maybe someone will do this for ffmpeg.
FWIW, for H264 this is not implemented in the demuxer either, the decoder just discards any frames that are not "clean".

Asking a demuxer to know about a long and ever growing list of video formats and be able to identify keyframes for all of them is just madness, so it will never do that. It will act on information inside the container metadata, and not try to interpret the video data inside it at all.
The decoder can handle all the video stuff then, including dropping any corrupted frames if this is implemented for the codec in question. It just isn't for HEVC, maybe some day someone will do it.

Ideally, videos should just come in containers that have key-frame info, like MP4 or MKV. Commercially, TS is only really used for broadcasts (and Blu-ray, but Blu-ray has extra metadata for clean seek points), and people are generally just too lazy to remux the videos after recording a broadcast, so shrug.
I wouldn't implement codec specific custom seeking for every codec out there, that would be madness, I fully agree with you there. However, there are only a handful of codecs which are commonly used in TS, so implementing some extra seeking support only for those few codecs might make some sense - depending on how much of a perfectionist you are.

Of course simply discarding unclean frames in the decoder works ok, too. However, that comes with its own set of limitations: E.g. if there's a key frame only every 10 seconds of playback, imagine the user seeks to a specific time frame, then playback will either have a "black screen" or corrupted frames for up to 10 seconds for every seek.

Ideally the demuxer would be clever enough to start demuxing from the nearest seek point *before* the desired time frame. Then the decoder would discard any frames prior to the desired time frame, and then the whole playback chain could do frame perfect seeks. I might be asking a lot here, but wouldn't that be needed for a perfect end user seek experience with TS files? The big question might be whether we "need" a perfect seek experience with TS files. But don't we developers all strive for a perfect end user experience?

[e-t172]

I currently have some 6Ch and 8Ch PCM samples placed within the .m2ts container, which engages LAV Audio Decoder just fine, but my surround sound amplifier is only detecting 2 channels.

Are you sure downmixing is disabled in LAV Audio, that your player doesn't have some downmixing/routing feature enabled, and most importantly, that the Windows sound device (in the control panel) is configured for 7.1 and not for stereo?

But don't we developers all strive for a perfect end user experience?

Well yeah, but there are hidden costs here. Consider that this would require complex code that would then have to be maintained (technical debt) and could make future changes harder. Maybe it could make it harder to add improvements that are more important than seeking-in-TS in the first place. Sometimes it's just not worth it because the potential consequences from the technical debt are larger than the immediate benefit.

[nevcairiel]

"Perfect" seeking in MPEG-TS would be incredibly slow. The format has no index, so even finding the timestamp we want is already quite a slow and heuristic process (a binary search, usually). Add on top of that going backwards and parsing frame headers, and it will probably be a noticeable slow-down again, especially over high-latency or slow-random-access connections (ie. network, or optical mediums). That IO APIs are not designed to read backwards doesn't help.

I will rather continue to advice people to remux to proper containers for offline playback, instead of "ab"using a streaming/broadcasting container format. There are people that have an even stricter interpretation and say that seeking in TS should just flat out not be supported at all, since the format isn't build for that.

[NikosD]

About H265(HEVC) - ffmpeg support detect and set key-frame marker. So - you can use it's after seeking as well as for MPEG2/VC1 in decoder. I use it in MPC-BE - and no artefact after seeking :)

I'm impressed by the way that MPC-BE x64 v1.4.4.265 handles .ts files.
No artifacts at all, just a minimal pause of the frame after seeking (much better than artifacts of course).

But I'm more impressed of the ability to decode 10bit H.264/H.265 videos without disabling P010/P016 output, that I have to disable using MPC-HC (LAV Video).

How is this even possible ?

I thought it was a bug of Intel drivers and as a matter of fact I posted a bug report today in Intel forums!

[nevcairiel]

Please move discussion about MPC-BE to its own thread.

[NikosD]

OK, but the discussion of 10bit - P010/P016 output is more appropriate here, because in LAV we have to disable it in order to decode the 10bit H.264/H.265 clips.

Is it a bug of Intel drivers or incompatibility of LAV - Intel drivers ?

Can you be more specific why isn't working with LAV and if there is any workaround for that ?

Because as I've already written above, I posted that to Intel forums in order to fix it!

Thanks!

[huhn]

this is a bug in the intel driver and has nothing to do with what lav does.

EVR from intel says it can handle p016 and than it fails that's all.

[clsid]

MPC-HC has a workaround for that P010 bug. MPC-BE probably just copied that.

Speaking of MPEG-TS, is program switching/selection functionality something we can expect soonish, or is that still low priority?

[NikosD]

MPC-HC has a workaround for that P010 bug. MPC-BE probably just copied that.


I'm using MPC-HC x64 v1.7.8.123 and LAV x64 0.64.38 and when I enable P010/P016 output in LAV properties I get a black screen when I'm trying to decode 10bit H.264/H.265 clips with any decoder (SW, DXVA)

How could I enable that workaround ?

[clsid]

It is applied automatically for EVR. If it doesn't work there must be a bug.
Edit: looking at the source, it seems only applied to vanilla EVR. See HookWorkAroundNVIDIADriverBug uses in the code.

The effect is the same as disabling P010, so you might as well just keep doing that.

[huhn]

madVR is the best "workaround" it can deal with all colorspaces lavfilter can output

[nevcairiel]

I think it was only enabled for P010 for NVIDIA, while the Intel bug is with P016, maybe MPC-HC didnt blacklist P016 in addition to P010, who knows.

[NikosD]

It is applied automatically for EVR. If it doesn't work there must be a bug.
Edit: looking at the source, it seems only applied to vanilla EVR. See HookWorkAroundNVIDIADriverBug uses in the code.

The effect is the same as disabling P010, so you might as well just keep doing that.

Well, it isn't applied even for vanilla EVR. I tried that too.
Disabling P010/P016 still is the only way for MPC-HC.

[P.J]

Upload original file :)
I'll capture it again in short time and upload it :)

I'm impressed by the way that MPC-BE x64 v1.4.4.265 handles .ts files.
No artifacts at all, just a minimal pause of the frame after seeking (much better than artifacts of course).

But I'm more impressed of the ability to decode 10bit H.264/H.265 videos without disabling P010/P016 output, that I have to disable using MPC-HC (LAV Video).

How is this even possible ?

I thought it was a bug of Intel drivers and as a matter of fact I posted a bug report today in Intel forums!

Agree, and I have to use copy-back mode with GTX960 :rolleyes:

[madshi]

"Perfect" seeking in MPEG-TS would be incredibly slow. The format has no index, so even finding the timestamp we want is already quite a slow and heuristic process (a binary search, usually). Add on top of that going backwards and parsing frame headers, and it will probably be a noticeable slow-down again, especially over high-latency or slow-random-access connections (ie. network, or optical mediums). That IO APIs are not designed to read backwards doesn't help.
Well, with TS you have to use random access to find the proper position in the file, anyway. So wouldn't it be possible to implement some clever algorithm like this: Average Bandwidth = file size / runtime. Max seek distance = statistic LAV collected during playback so far (initialized to maybe 5 seconds). So if a seek occurs, you could jump back about twice the max seek distance, just to be safe, and then simply start demuxing from that point. No further checks *at all*. You would simply start demuxing "too early". The only negative side effect would be that it would take longer for a seek to take effect. But the delay would almost completely depend on the decoder. So with a fast decoder (e.g. MPEG2 and probably also h264) it might not be noticeable at all. With h265 it would be noticeable, of course. Shouldn't this "simple" method of starting demuxing too early automatically take care of all graphical corruption and provide frame perfect seeking? The video and audio renderers are supposed to automatically delete frames which are "too early", so there's nothing else LAV Splitter would have to do, I think. Ok, some users might have different priorities than others. I'd prefer frame perfect seeking over fast seeking times. Other users might prefer fast seeking and be willing to live with non-perfect seeking instead. So maybe there would have to be an option for this.

Just throwing around some ideas. Feel free to ignore if you don't like it.

[Arm3nian]

Well, try as I might, I'm unable to figure out how to reliably pass multi-channel PCM audio via HDMI to my surround sound amplifier using LAV injunction with MPC-BE.

I currently have some 6Ch and 8Ch PCM samples placed within the .m2ts container, which engages LAV Audio Decoder just fine, but my surround sound amplifier is only detecting 2 channels.

I'm sure I've had this working in the past :eek:

It should be plug and play.

What are the outputs at lav and the mpcbe audio renderer? Are both showing multichannel output? The lav output goes to the renderer, and the renderer outputs via hdmi. My onkyo receiver has internal mixing options that you can select. If I start playing a 5.1 source then it automatically switches to 5.1 mpcm, but I can change it to stereo if I want. Maybe you need to manually select mpcm on the receiver. Also make sure your system is configured as 5.1/7.1 in the windows mixer just in case wasapi isn't working properly.

[jkauff]

The software that comes with Hauppauge video capture hardware outputs a .TS file, but provides an option to convert the file to .MP4. It makes sense to me that the burden of delivering a file to the end user with a better container for playback should rest with the capture program, rather than expecting LAV to handle the quirks of .TS files.

[SeeMoreDigital]

It should be plug and play.

What are the outputs at lav and the mpcbe audio renderer? Are both showing multichannel output? The lav output goes to the renderer, and the renderer outputs via hdmi. My onkyo receiver has internal mixing options that you can select. If I start playing a 5.1 source then it automatically switches to 5.1 mpcm, but I can change it to stereo if I want. Maybe you need to manually select mpcm on the receiver. Also make sure your system is configured as 5.1/7.1 in the windows mixer just in case wasapi isn't working properly.Thanks...

I ended up having to uninstall my 'Realtek High Definition Audio' drivers. After re-booting my computer the audio drivers re-installed themselves and all is well with (7.1) multi-channel PCM audio again. What a pain in the arse that was ;)

Cheers

[macycat]

My version of the HDPVR comes with arcsoft capture software, and one can select .ts, .m2ts, or .mp4. I usually select the .m2ts version. While seeking on a video file in MPC-HC, I usually see a brief flash of garbled video, and then things sync up.

Does anyone know if there is an advantage to .m2ts vs. .ts vs. .mp4 for playback using LAV splitter/video filters?


The software that comes with Hauppauge video capture hardware outputs a .TS file, but provides an option to convert the file to .MP4. It makes sense to me that the burden of delivering a file to the end user with a better container for playback should rest with the capture program, rather than expecting LAV to handle the quirks of .TS files.

[Pat357]

My version of the HDPVR comes with arcsoft capture software, and one can select .ts, .m2ts, or .mp4. I usually select the .m2ts version. While seeking on a video file in MPC-HC, I usually see a brief flash of garbled video, and then things sync up.

Does anyone know if there is an advantage to .m2ts vs. .ts vs. .mp4 for playback using LAV splitter/video filters?
The MP4 format should be better for seeking : much less or no image distortion after seek.
Of course this is in the assumption that the MP4 is properly muxed by your software. Try it and see the difference !!

[captainadamo]

My version of the HDPVR comes with arcsoft capture software, and one can select .ts, .m2ts, or .mp4. I usually select the .m2ts version. While seeking on a video file in MPC-HC, I usually see a brief flash of garbled video, and then things sync up.

Does anyone know if there is an advantage to .m2ts vs. .ts vs. .mp4 for playback using LAV splitter/video filters?

m2ts should theoretically be better at seeking over plain ts since it was specifically modified for random-access media, but MP4 is still going to be the best choice of the three if seeking is an important container attribute.

[SeeMoreDigital]

m2ts should theoretically be better at seeking over plain ts since it was specifically modified for random-access media, but MP4 is still going to be the best choice of the three if seeking is an important container attribute.Don't forget Matroska. It's mkv container is no slouch when it comes to seeking ;)