LAV Filters - DirectShow Media Splitter and Decoders

[SamuriHL]

Decoding was certainly better for me, probably because the ATMOS extensions are ignored when decoding, it still wasn't perfect. I had issues with that, as well.

[SamuriHL]

I want to update here as I've already posted on the JRiver MC forum. The ripping tool I use updated today with a fix for ATMOS sub-types. So I re-ripped Incredibles 2 MKV. LAV is still having audio drops and eventually the audio completely drops out. Playing the same file on my SHIELD shows no audio drops at all. Hopefully Nev can nail this one down and find the issue.

[Aleksoid1978]

I want to update here as I've already posted on the JRiver MC forum. The ripping tool I use updated today with a fix for ATMOS sub-types. So I re-ripped Incredibles 2 MKV. LAV is still having audio drops and eventually the audio completely drops out. Playing the same file on my SHIELD shows no audio drops at all. Hopefully Nev can nail this one down and find the issue.

Re-upload sample.

[SamuriHL]

I didn't upload a sample. I won't have time today to make one but should be able to tomorrow.

Sent from my Pixel XL using Tapatalk

[nautilus7]

Hi, I was given a recording from a satellite channel (https://www.sendspace.com/file/e40odh). The file contains an AC3 audio stream, which is not decoded at all (no sound) with lav filters. Even ffplay can't decode it:

Could not find codec parameters for stream 1 (Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels, fltp): unspecified sample rate

Is there anything that can be done to get sound? The user who sent it to me said his satellite receiver can decode it... :confused:

Thanks!

[LigH]

Funny sample. DGIndexNV locks up, trying to open it to demux the audio. MKVToolnix-GUI ignores the stream; tsMuxeR GUI as well. PVAStrumento can't demux it.

TSPE 0.301 calls it: AC-3 (ATSC A/53B audio).

DGAVCIndex reports an interesting issue:

---------------------------
Audio Detection Mismatch
---------------------------
The audio type determined from reading the PAT/PMT program information (AC3)
does not match the detected audio (MPA). In many cases, this is caused by emulation
of audio headers (false detection) and the PAT/PMT type is the correct type.

Hit Yes to use the PAT/PMT type. Hit No to use the detected type. Hit Cancel to disable this stream.
---------------------------

Sounds like there is in fact MPEG Audio in a stream multiplexed as if it was AC-3. But neither mode produces a sensible demultiplexed audio stream.

[manolito]

This would be very weird and uncommon:
I have never heard of any SAT broadcasts transmitting AVC video with MPA (MP2) audio. FOR SD broadcasts it is MPEG2 video with either MPA or AC3 audio, for HD broadcasts it is AVC video with AC3 audio.

[LigH]

Well, DGAVCIndex may be right that it is not one of the common AC-3 encodings; but it may be wrong that it is MPA instead. The video is AVC.

[nautilus7]

Hi again... thanks for the information.

What is more interesting about this audio is that whether it plays ok or not depends on the satellite receiver used. The user who is giving me these samples has 2 receivers, one of which is able to decode the audio and the other is not. So, I asked for new samples. Here are 2 recordings (https://www.sendspace.com/file/etlwlz): One is made with the "good" receiver where audio is decoded fine, and the other with the "bad" receiver where audio is not decoded. The audio in this channel is indeed AC3.

ffplay from the "good" recording:
Stream #0:1[0x7e6]: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
ffplay from the "bad" recording:
Stream #0:1[0x7e6](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels, fltp


The exact same thing happens for him on a different channel as well. So here's another pair of recordings (https://www.sendspace.com/file/h183ko), one with audio ok ("good" receiver), the other with no audio ("bad" receiver). The audio in this channel is MP2.

ffplay from the "good" recording:
Stream #0:1[0x1f5]: Audio: mp2, 48000 Hz, stereo, s16p, 192 kb/s

ffplay from the "bad" recording:
Stream #0:2[0x1f5]: Audio: mp3 ([4][0][0][0] / 0x0004), 0 channels

[LigH]

Quite certainly LAV Filters is not to be blamed here. It can only detect correctly flagged and stored content. I would suggest to discuss that in a separate thread...

[nautilus7]

That was my thought after getting the new samples with sound. Perhaps I'll make a new thread in the audio section. Thanks.

[dbezerra]

Re-upload sample.

There is no need to upload new samples. The original one I shared before works just fine on ShieldTV (bitstreaming Atmos) but hit dropouts when playing on Windows with Lav+MPC-HC or DSPlayer.

[SamuriHL]

There is no need to upload new samples. The original one I shared before works just fine on ShieldTV (bitstreaming Atmos) but hit dropouts when playing on Windows with Lav+MPC-HC or DSPlayer.

Which is exactly the same behavior I'm seeing even with the new rip I did.

[Damien147]

Hello!I can finally run high bitrate 2160p(:)) but...
Do I lose picture quality running D3D11(native) instead of D3D11 copy back?Wanted to try copy back but when I set hardware device it returns to automatic.
GPU:RX 470(polaris)

[sneaker_ger]

No quality loss with D3D11 native.

[Damien147]

Bye bye software decoding then.Thank you.:)

[nautilus7]

Dobly truehd tracks with 7.1 channels muxed in mkv are displayed as "7.1".
Dobly e-ac3 tracks with 7.1 channels muxed in mkv are displayed as "8 channels" instead.

See attached picture:

http://i65.tinypic.com/11b6dk0.png

This is not an issue of matroska, as it only stores a single number for the total number of channels (2, 6, 8, etc) and not the layout.

The layout information is something that lav filters find, probably by bitstream parsing or something. But whatever they do, it's not done for the eac-3 tracks.

This is purely a cosmetic issue, but would be nice if it could be fixed. Thanks.

[nevcairiel]

I wouldn't expect that to change, really. Determining the proper channel layout for Blu-ray style eac3 is kinda complicated, and its plenty that the decoder knows how to do it, the demuxer really doesn't need that info, and it would be complex code to add for cosmetics.

[nautilus7]

OK, I see. Thanks.

[Aleksoid1978]

Here is a link to the first 5min of Incredibles 2 UHD with Atmos.

https://ufile.io/1vw1x

Make sure you watch from the beginning. Most of us see an audio drop around the 3:17 mark, but not if you just skip to somewhere close to it (which could give a clue to what is causing it - a buffer issue?)

I check playback in MPC-BE on my A/V receiver(it's support TrueHD but don't support Atmos extension) - and have no drop. Play from start for end of sample.

[SamuriHL]

Yea, it's without a doubt an issue with the ATMOS extensions. People who've decoded to PCM report no problems, as well.

[Aleksoid1978]

Yea, it's without a doubt an issue with the ATMOS extensions. People who've decoded to PCM report no problems, as well.

I'm test on bitstream - no drops.

[SamuriHL]

I'm test on bitstream - no drops.

Bitstreaming the TrueHD only or ATMOS? Cause it matters.

[huhn]

as he said before his AVR doesn't support atmos.

[SamuriHL]

Yup...and as I said before, it's only bitstreaming the ATMOS extensions that shows the issue. ;)

[dbezerra]

I'm test on bitstream - no drops.

Test only the TrueHD piece is not enough to reproduce the problem. You need an Atmos capable receiver to reproduce it.

[Manni]

I'm test on bitstream - no drops.

Bitstreaming the TrueHD only or ATMOS? Cause it matters.

as he said before his AVR doesn't support atmos.

Yup...and as I said before, it's only bitstreaming the ATMOS extensions that shows the issue. ;)

I tested the Incredibles 2 file bitstreaming Atmos (Denon X8500H, see my sig). No drop. MPC-BE+LAV latest.

You might need to list your software + AVR to narrow this down, because not everyone gets these drops.

[SamuriHL]

My software is J River MC. And I definitely get drops on my Pio VSX-303 receiver.

[Manni]

My software is J River MC. And I definitely get drops on my Pio VSX-303 receiver.

You could try with MPC-BE (using latest external LAV) and see if you still get drops. If not, that would rule LAV out and you could ask jRiver to fix it.

I’m not saying you are not getting drop. I am saying that not everyone does, and that here LAV works fine with this file. See the rest of my config in my sig, anything else could be a contributing factor (including OS or GPU driver version).

If everyone having this issue posts their detailed software and hardware config, it might help those affected to find the common denominator. If Nevcairiel can’t reproduce, it is unlikely to get fixed otherwise.

[Aleksoid1978]

You can try MPC-BE without using LAV.

[SamuriHL]

I've tried using MPC-HC with its internal LAV and I still get drops.

[SamuriHL]

You can try MPC-BE without using LAV.

That, however, was an interesting idea. I'm not getting drops with this. Definitely seems to be pointing to something with LAV.

EDIT: Spoke too soon. Nope, drops with this, as well, just in different spots.

EDIT 2: On a hunch I tried going back to the driver version Manni uses and it did not change anything. Thought it could be an nVidia issue. I'm on 416.94 (I won't touch the 417.xx drivers yet until they fix the HDR issues.....AGAIN). Just trying to give as much info as I can to help figure out what's going on. But drops in MPC-xx with and without internal LAV filters are still happening.

[mikhaelkh]

VLC 3.0.5 released with AV1 decoder based on dav1d library, but still libaom decoder by default.

[dbezerra]

That, however, was an interesting idea. I'm not getting drops with this. Definitely seems to be pointing to something with LAV.

EDIT: Spoke too soon. Nope, drops with this, as well, just in different spots.

EDIT 2: On a hunch I tried going back to the driver version Manni uses and it did not change anything. Thought it could be an nVidia issue. I'm on 416.94 (I won't touch the 417.xx drivers yet until they fix the HDR issues.....AGAIN). Just trying to give as much info as I can to help figure out what's going on. But drops in MPC-xx with and without internal LAV filters are still happening.

I also tried with MPC-BE and its internal filters. No go - drops as well. The same MKV playing from the same server works just fine on NVidia shield with the same receiver (Denon 3200) and JVC RS500 projector. The only variables are Windows 10 (Fall Edition), NVidia 1080 and MPC-HC+Lav filters/MPC-BE.

[SamuriHL]

I also tried with MPC-BE and its internal filters. No go - drops as well. The same MKV playing from the same server works just fine on NVidia shield with the same receiver (Denon 3200) and JVC RS500 projector. The only variables are Windows 10 (Fall Edition), NVidia 1080 and MPC-HC+Lav filters/MPC-BE.

Are you getting the drops in the same place as MPC-HC with LAV when playing with MPC-BE with internal filters? For me the drops are in different spots which is why I originally said it was good. It took a bit longer, but, it started happening. I'm on the latest Windows 10 build with all the updates, the last nVidia 416 driver (come on nVidia), and a 1060 ggb.

[Undead Sega]

Its a DirectShow filter, it can be used in any software which uses DirectShow for video decoding - which WMP is one of. Software which doesn't use DirectShow also cannot use a DirectShow filter. See how that works? :D

So sorry for my late reply, things in life got in the way and there has been ups and downs (back to being down again)!

Well when I used Premiere Pro awhile back with ffdshow at default settings, I can see it was active and doing the decoding of my MPEG-2 sources, which was unfortunately causing some glitches cause of the two programs conflicting, thus how I discovered it was doing the decoding (when I disabled it).

Also it was further evident when I saw the taskbar icon appearing at the bottom corner :D

So I can assure you that ffdshow was definitely doing some work, you can actually force it to in the setting of the program:
https://forum.doom9.org/attachment.php?attachmentid=16633&stc=1&d=1546045514

Is there no way you can implement the same thing for LAV filters??? It would help sooo much! :)

[ryrynz]

Upload your images somewhere else.

[LigH]

Usual suggestions: frupic, tinypic, imgur...

[clsid]

ffdshow only has a blacklist/whitelist option, which defines which applications are allowed to use it.

Which decoder is used is not controlled by the filters themselves. The application decides what to use. When using the standard graph builder it uses whatever decoder is set as preferred in Windows for a specific mediatype, or whichever filter has the highest merit.

You can use Codec Tweak Tool to change preferred decoder settings.

[Undead Sega]

So how does ffdshow is able to decode video within Premiere Pro and LAV filters can't? :(

[LigH]

If Premiere Pro uses the default graph builder, it asks the DirectShow system: "Which filter can help me decoding this source?" - and ffdshow yells the loudest: "Here, I can best, use me!" ... so if you want to give LAV Filters a chance, you first need to tell ffdshow: "Shup up, this kind of source is not your task." by either deactivating this format in its DirectShow filter configuration, or even by uninstalling it ... or by making LAV Filters yell even louder than ffdshow (which is not easy, because ffdshow is already quite loud).

But if Premiere Pro uses a different algorithm to build its filter graphs, how shall we know what to do?

[el Filou]

Funny sample. DGIndexNV locks up, trying to open it to demux the audio. MKVToolnix-GUI ignores the stream; tsMuxeR GUI as well. PVAStrumento can't demux it.
TSPE 0.301 calls it: AC-3 (ATSC A/53B audio).
DGAVCIndex reports an interesting issue:
Sounds like there is in fact MPEG Audio in a stream multiplexed as if it was AC-3. But neither mode produces a sensible demultiplexed audio stream.Sorry for the off-topic, but TS Doctor says the audio stream is (partly) encrypted and that's why it won't decode:Broadcast standard selected: DVB
Broadcast standard detected: DVB
PES WARNING: PID 07EA scrambled 66,67%

2027 (07EB): 90% = H264 Video (PES_StreamID E0 = Video_Stream_0) {00000001} [PCR,PTS,DTS]
2026 (07EA): 9% = [SCRAMBLED 66,67%]
0 (0000): 0% = PAT
2028 (07EC): 0% = PMT

Selecting PMT with PID 2028 (07EC) at position 00000725
CRC OK!
Conforming PMT entry 1 to DVB standard
Deleting PMT entry: PID 2025 (07E9) type 134 = Private stream type Audio DTS (DTS)
PID 07EA is encrypted and will be removed

[halcom]

To anyone that has compiled LAVFilters 0.73.1.
Which version of ffmpeg are you using?
1)Tried cloning the master here (v3.4):
https://github.com/Nevcairiel/FFmpeg
First error is "missing avpriv_mpegts_add_stream"
2) Tried fork V3.3 from MPC-HC
https://github.com/mpc-hc/FFmpeg/releases
First error is "missing av_demuxer_iterate"
3) Official ffmpeg site
https://www.ffmpeg.org/download.html
Missing lots of things as expected.
Please let me know if I am posting to the wrong area.

Any help greatly appreciated!

[nevcairiel]

The version of FFmpeg LAV uses is referenced both in the readme as well as the first post in this thread, as well as directly linked to the sources through a Git submodule. It should really not be that hard to find it.

[Megalith]

Why does LAV Audio output in 32-bit float for 24-bit TrueHD and DTS-HD MA tracks? Doesn't that mean the track is no longer bit-perfect?

EDIT: Okay, apparently it does on a technical level, but some DACs seem to sound different when the bit-depth is upconverted...

[huhn]

integar -> float conversation are "lossy".

are you using the mixer or something? this will turn the audio into float point because that's more "accurate" lossy processing is usually better done in float with audio in mind.

and you wouldn't even believe what a DAC has to do to lossless audio before it is doing the conversation...

[Megalith]

Oh, duh, yes...the mixer is active, as I only have a stereo setup.

[lvqcl]

but some DACs seem to sound different when the bit-depth is upconverted...
No, they don't.

[amichaelt]

Why does LAV Audio output in 32-bit float for 24-bit TrueHD and DTS-HD MA tracks? Doesn't that mean the track is no longer bit-perfect?

No, single-precious float can represent all possible 24-bit integers.

https://en.wikipedia.org/wiki/Single-precision_floating-point_format

EDIT: Okay, apparently it does on a technical level, but some DACs seem to sound different when the bit-depth is upconverted...

There's no "upconverting" unless you think that 24 and 24.0 are different numbers.

[nautilus7]

Sorry for the off-topic, but TS Doctor says the audio stream is (partly) encrypted and that's why it won't decode:
Hi, yes you are correct. I was able to solve the problem by fixing a descrambling bug in the software. Audio plays ok now. Thanks.