LAV Filters - DirectShow Media Splitter and Decoders [Archive] - Page 489

VictorLS

5th April 2021, 23:57

I don't have to care what you think, and those options will never happen.
I guess many people want to have one universal enough good product than many special (but even worse than universal) products for each case.
I don't get anything from it.
If you don't want to get 250$ (https://forum.doom9.org/showthread.php?p=1934493#post1934493) it's your decision ;)
wanezhiling
What about your TigerLake and mpv - it can use HW acceleration (without Video Processing) in cases where LAV Video Decoder and others couldn't?

wanezhiling

6th April 2021, 03:54

wanezhiling
What about your TigerLake and mpv - it can use HW acceleration (without Video Processing) in cases where LAV Video Decoder and others couldn't?
mpv only supports quicksync for av1, too slow.
for hevc vp9 h264, mpv seems a bit faster than mpc-be.

well, i stick with mpc-be:)

nevcairiel

6th April 2021, 08:27

If you don't want to get 250$ (https://forum.doom9.org/showthread.php?p=1934493#post1934493) it's your decision ;)

This is an entirely different request, for exposing additional hardware capability and not a cheap performance hack that degrades quality, and will most likely be supported in the re-designed NVDEC backend (which is part of the reason it is infact being replaced, as the old CUVID one has limitations), as I have already responded to before.
But, I also wouldn't do a quick hack to get it working just because someone put some money up. Thats just not my goal with LAV.

monohouse

6th April 2021, 09:57

thank :) 0.75 nice work :)

VictorLS

6th April 2021, 15:52

wanezhiling, nevcairiel
Thanks for your replies

wanezhiling

11th April 2021, 05:31

Question about HDR on Intel

Hi nevcairiel, do you have Intel GPUs (7th Kabylake and above)? Can you test whether the image on Intel (https://i.postimg.cc/bqNsPVzZ/hdr-evr-on-intel.png) is different with the one on AMD/NVIDIA (https://i.postimg.cc/3YZdPQHM/hdr-evr-on-amd-nvidia.png) when playing any HDR videos(for example (https://mega.nz/file/Bo1SlZSK#A5uBPSygx-3V0H_StNyWwLNp4fZQA6Gd8z7ZKuo_lR4)) with vanilla EVR. And do you know how does intel process?

ps: If you use wmp12 (microsoft's built-in decoder), the image will be the same as AMD/NVIDIA even on intel.

nevcairiel

11th April 2021, 09:07

I do not. But EVR doesnt do any HDR processing, any outcome will be wrong. The difference is likely from obeying the color matrix or not, and the MS decoder just not sending that information. But as said, neither properly reproduces HDR, so its always wrong.

wanezhiling

11th April 2021, 11:24

Thanks.
Some developers told me that's intel's problem, but a workaround on decoder side can solve this.
Maybe you can investigate further once you got a iGPU. Anyway, it's up to you.

edit: mpc-be r6170 (https://sourceforge.net/p/mpcbe/code/6170/) changed codes for this situation. because Intel automatically tries some transformation when it met hdr videos (VideoTransferMatrix = BT.2020) with evr.

VictorLS

12th April 2021, 09:57

wanezhiling
Many thanks - I saw the same color distortion (it looks much worse than without any transformation on my own) with ordinary EVR (so not EVR-CP) - I guess you've called it vanilla EVR - with HDR videos when I tried with Intel's Comet Lake with integrated UHD Graphics 630 and igfx_win10_100.9316.exe driver

nevcairiel

12th April 2021, 10:59

edit: mpc-be r6170 (https://sourceforge.net/p/mpcbe/code/6170/) changed codes for this situation. because Intel automatically tries some transformation when it met hdr videos (VideoTransferMatrix = BT.2020) with evr.

But BT.2020 does not mean HDR, and sending another flag then that one would just be plain wrong. I don't think this issue is understood well enough to make blanket changes that practically make the decoder lie just to make it look wrong in another fashion, so I won't.
It does sound to me like its actually processing BT.2020 (like its supposed to), but you just don't want that for some reason, and thus lie to the renderer.

wanezhiling

12th April 2021, 11:20

But BT.2020 does not mean HDR, and sending another flag then that one would just be plain wrong. I don't think this issue is understood well enough to make blanket changes that practically make the decoder lie just to make it look wrong in another fashion, so I won't.
It does sound to me like its actually processing BT.2020 (like its supposed to), but you just don't want that for some reason, and thus lie to the renderer.
so the best solution is reporting to intel? let intel change in their driver?

this does affect all bt.2020 videos, indeed. I can't believe no intel users ever found it before? ....:devil:

VictorLS

12th April 2021, 11:26

so the best solution is reporting to intel? let intel change in their driver?
I guess answer on both your questions is Yes ;)
May be you'll ask Intel how to activate their hardware acceleration of H265 4:2:2 and 4:4:4 in Intel Xe (Tiger Lake)?

*MidnightWatcher*

13th April 2021, 04:07

Just updated from 0.74.1 to the new 0.75. Unfortunately, all video streams from my FTP server now take around 20 seconds before the videos start playing (local files play immediately). This never happened under 0.74.1 -- they all play immediately. Any idea what setting, if any, I need to change in 0.75, or should I just stick with 0.74.1?

Player: MPC-BE 1.5.6 x64
Renderer: madVR b128

Thanks in advance!

Update: If I only install the LAV Video Decoder 0.75 and keep the splitter and audio decoder at 0.74.1, the videos streamed via FTP play immediately, but if the splitter or audio decoder 0.75 are installed, it takes about 20 seconds before the video begins playing.

RealSnoopyDog

13th April 2021, 09:09

It would be helpful to know for which file format this happens for you. I don't have problems where starting a video stream takes 20 seconds or more on a network storage. They all start immediately (plain mpeg and mkv)

SeeMoreDigital

13th April 2021, 09:28

Just updated from 0.74.1 to the new 0.75. Unfortunately, all video streams from my FTP server now take around 20 seconds before the videos start playing (local files play immediately). This never happened under 0.74.1 -- they all play immediately. Any idea what setting, if any, I need to change in 0.75, or should I just stick with 0.74.1?
When was the last time you disabled the mains power from all your gear, waited between 30 to 60 seconds, and switched everything back on again!?

My Synology NAS was behaving strangely a few weeks ago after an update. After "switching it off and on again"... It's working fine ;)

el Filou

13th April 2021, 10:37

If I only install the LAV Video Decoder 0.75 and keep the splitter and audio decoder at 0.74.1, the videos streamed via FTP play immediately, but if the splitter or audio decoder 0.75 are installed, it takes about 20 seconds before the video begins playing.I know this could be a bit time consuming, but what you could do is try to install each of the nightlies here: https://files.1f0.de/lavf/nightly/0.74/ and see after each upgrade/downgrade if the problem appears/disappears.
Proceed using a sort of "divide search": install a build from the middle of the list, like 0.74.1-59, check if the problem happens, if it does then the issue was introduced in a build between 0.74.1 and that one, if it doesn't it was in a later one, then repeat the same process with the smaller resulting selection.
At worst it should take you only installing 6 of those to pinpoint which one exactly introduced the issue.
Then you can see all the codes changes that happened here: https://github.com/Nevcairiel/LAVFilters/compare/0.74.1...master and hopefully find something that explains it and nev can take a look at it.It would be helpful to know for which file format this happens for you. I don't have problems where starting a video stream takes 20 seconds or more on a network storage. They all start immediately (plain mpeg and mkv)What protocol? Maybe it only affects FTP.

*MidnightWatcher*

13th April 2021, 15:12

*MidnightWatcher*

13th April 2021, 15:14

When was the last time you disabled the mains power from all your gear, waited between 30 to 60 seconds, and switched everything back on again!?

My Synology NAS was behaving strangely a few weeks ago after an update. After "switching it off and on again"... It's working fine ;)
It plays fine with 0.74.1, but not with 0.75. If it were the server I'd have issues regardless of version.

nevcairiel

13th April 2021, 16:28

*MidnightWatcher*

13th April 2021, 18:35

Does it actually use LAV Splitter to access the FTP server, or is it using an external URL Source Filter? More information is more better. :)

PS:
Issues are not always as straight forward as you might think. Restarting your NAS takes you as much time as declaring that its not the cause. :D
Hi nev, I restarted the FTP server and still the same.

I'm using Kodi with MPC-BE as the external player, and MPC-BE is set up to use only LAV for splitter, audio, video. They are all active in the task bar also when a video is playing. Does this answer your question?

clsid

13th April 2021, 19:40

*MidnightWatcher*

14th April 2021, 04:56

MPC-BE Menu > Play > Filters

It is probably using "File Source (URL)", which may be caching the whole file before playback starts.

You can edit this registry key to change the source filter:
HKEY_CLASSES_ROOT\ftp
LAV = {B98D13E7-55DB-4385-A33D-09FD1BA26338}

MPC-BE 1.5.7.6005

Filters currently loaded:
- Default DirectSound Device
- XySubFilter (=> madVR)
- madVR Renderer
- Audio Switcher
- LAV Video Decoder
- LAV Audio Decoder
- LAV Splitter Source

I tried updating FTP Source Filter value data in the registry as suggested, but still takes 20 seconds to start playing a video.

biship

14th April 2021, 11:23

For me playing files from my Synology NAS it takes 5-7s before the video starts, and oddly, the screen is also blank for the first 5s of the video. I can hear the audio. All MKVs.

*MidnightWatcher*

14th April 2021, 14:28

For me playing files from my Synology NAS it takes 5-7s before the video starts, and oddly, the screen is also blank for the first 5s of the video. I can hear the audio. All MKVs.
It takes 5-7 second before playing, plus another 5 seconds for the video to be displayed? Curious -- is your connection "fast ethernet" (10/100) or gigabit (10/100/1000)? The blanking sounds like your display is adjusting to the frame/refresh rate. My JVC projector takes about 6 seconds, which is normal.

clsid

14th April 2021, 22:02

@nevcairiel
I am debugging a hang in m_pDXVA2Allocator->GetBuffer()
The free list is empty/null and m_lCount=m_lAllocated=23

I assume that this situation of all buffers being in use should not happen under normal conditions?
This problem occurred for a user with heavy GPU usage by Firefox. Could it be that a buffer is not freed (or re-used) when a failure occurs somewhere in the DXVA2 code (of FFmpeg)?

VictorLS

18th April 2021, 17:06

Here's fp3.mkv (9 MB) https://TransFiles.ru/2t9vj well visible colorshift issue (http://forum.doom9.org/showthread.php?p=1919062#post1919062) but this time it isn't decoder's problem because it's progressive so it's not mine reencoding issue.

huhn

18th April 2021, 19:24

this file has a really low quality so what has this todo with lavfilter?
this should be a simple chroma luma channel mismatch by 1 frame.

VictorLS

18th April 2021, 21:55

this file has a really low quality so what has this todo with lavfilter?
With LAVFilters-0.75.0-2 YADIF still doesn't work on Formula1.2019.Round06.Monaco.Race.Sat.Feed.1080i.H264.Multi.Language_fromMKVtsMuxerNotHDMVcompatible.ts to solve colorshift issue on such 4:2:2 SAT feeds on every videocard ;)
this should be a simple chroma luma channel mismatch by 1 frame.
Seems you're right - each frame from two serial frames.

brazen1

22nd April 2021, 03:07

When I bitstream any audio format (incl DTS) with my AVR on, all is well and the AVR displays the correct format is decoding.
When I turn my AVR off I get down converted stereo audio through my 2 panel speakers and all is well.

However, DTS and DTS HD do not produce any audio with the AVR off using MPC-HC/BE which use LAV Filters.
I am able to play DTS audio with the AVR off when I use the Kodi internal VideoPlayer. Same with other players such as PowerDVD and DVDFab Media Player. Of course it's in 2chl which is fine.

I notice if I unselect DTS bitstreaming in the LAV Audio Configuration settings, both MPC players produce DTS audio (2chl) just like other players when the AVR is off.
This leads me to believe I have a problem with LAV Filters exclusively and I'm seeking help.
I'm using 0.75.0. I tried 0.71.0 and they had the same behavior.
I don't think the fix for me is to manually enable/disable DTS bitstreaming per AVR on/off state is it?

Aleksoid1978

22nd April 2021, 04:04

brazen1

22nd April 2021, 05:38

Try internal MPC-BE audio decoder.

I changed to MPC audio renderer from DirectSound default and vice versa using MPC-BE. I unchecked LAV Audio Decoder. I ticked DTS for Internal Audio Decoder. I restarted title. No change.

I did the same with MPC-HC. No change. I unticked Allow bitstreaming and of course it worked since it's similar to turning off DTS in LAV audio. I can't find a similar Allow bitstreaming in MPC-BE but I want to bitstream when my AVR is on anyway understanding this is just a test.

Does this confirm that since internal decoder and external LAV decoder produce the same negative result, that something else is the root of my problem? Windows or NVidia HDAudio driver - except Kodi, PDVD, FAB players do work. Both MPC players? Maybe it's just exclusive to my system - I'm lucky like that :confused: Thank you for the suggestion.

Aleksoid1978

22nd April 2021, 07:35

MPC-BE audio decoder have options "Pass-through (S/PDIF, HDMI)".

el Filou

22nd April 2021, 12:56

What could be happening is that Windows caches the EDID information from the AVR stating that the HDMI sink supports DTS and your TV doesn't supports DTS but the info is not updated when the AVR is turned off. I don't know if that would be a Windows problem or an HDMI audio driver problem.
(Edit: maybe the other players distinguish between sink devices using the device name? Does the device change depending on whether your AVR is on or off?)

Does it also happens when you cold boot Windows with the AVR off?

brazen1

22nd April 2021, 16:15

MPC-BE audio decoder have options "Pass-through (S/PDIF, HDMI)".

Yes, I know and they are all ticked.

What could be happening is that Windows caches the EDID information from the AVR stating that the HDMI sink supports DTS and your TV doesn't supports DTS but the info is not updated when the AVR is turned off. I don't know if that would be a Windows problem or an HDMI audio driver problem.
(Edit: maybe the other players distinguish between sink devices using the device name? Does the device change depending on whether your AVR is on or off?)

Does it also happens when you cold boot Windows with the AVR off?

You are correct. My panel does not support DTS but shouldn't something in the chain down convert to PCM or something the panel speakers can handle? It doesn't support ATMOS either but I get audio? Cold boot with AVR off makes no difference.

I don't know how to check possible device name change dependent on AVR state?

el Filou

22nd April 2021, 17:24

Normally, LAV's "Fallback to PCM if Bitstreaming is not supported" should take care of that, but maybe something is giving it a wrong information on whether DTS is supported?

I have no idea how to check if the device is identified differently, I don't use passthrough or ARC with my AVR, maybe someone else knows? But there must be a way for those other playback apps to accurately determine that DTS isn't supported while LAV decoder fails.

Maybe try this utility: https://www.entechtaiwan.com/util/moninfo.shtm and compare what's displayed in the real-time and registry pages.

Tsukinyan

25th April 2021, 20:41

I've done a bunch of searching of a few different threads on this forum and I think I understand the difference between "Normalize Matrix" and "Clipping Protection", but I'm not 100% confident. I'm hoping someone can correct me or verify my thoughts below.

- Normalize Matrix = lowers the level of the entire audio stream across all channels to make sure no levels go above 1.00. Thus the distance between the lowest level and the highest level would be preserved. In practice, the volume difference between a character whispering in one scene and an explosion in a different scene would be the same with normalize matrix on or off.

- Clipping Protection = if a stream were to go above 1.00, instead play it at 1.00. Thus if the lowest level was 0.09 and the highest was 1.04 (difference of 0.95), clipping protection would make the highest 1.00 and the difference between lowest and highest level would be 0.91. In practice, the volume difference between a character whispering in one scene and an explosion in a different scene would be different with clipping protection on or off.

I'm making up numbers in those explanations, but I'm mostly trying to convey the theory behind the settings and not give realistic examples. That said, if my explanation of Clipping Protection is correct, would this volume difference actually be noticeable? I mostly watch at my desktop using high-end headphones connected to a fairly powerful AMP, so it's less important to me if the overall volume is lowered slightly. But it would bother me if I knew the difference between peak lows and highs was being modified (even if I couldn't notice it).

LigH

26th April 2021, 07:21

Normalize won't certainly reduce the volume (that usually happens only during a downmix of multi-channel audio to stereo, with or without Dolby ProLogic surround matrix, where a weighted sum of more than 2 channels may exceed 100% volume). It may as well rise it in case the peak of the source is below the target maximum (which you may set below 100%; rising volume is probable for stereo audio without dynamic compression). In general, normalization needs a look-ahead to discover the peak. For offline processing it may be the entire audio. In a real-time filter it may be a sliding window being pre-decoded before playing, but with a limited range, which may cause alternating loudness.

I am not sure which kind of implementation LAV Filters uses for Clipping Protection; I guess it is a kind of dynamic compression. There may be a simple filter which "flattens the peaks" per sample, or a more elaborate filter which dynamically reduces the volume of short audio blocks... "dynamic" is about what you mean as difference between levels, but there are standards to calculate it in decibels.

Asmodian

26th April 2021, 22:40

I think normalize matrix is very different from a normal normalize.

Normalize matrix is simply changing the weights of a downmix matrix so it is impossible for the downmix to go over 100% in any channel, isn't it? This is always quieter, but will never clip.

Clipping protection doesn't care what the lowest level is at all, it simply lowers the total volume to prevent clipping anytime the volume goes too high. This has the somewhat odd effect of causing the average volume level to be lower after a loud noise that would have clipped at the previous level. It is like a single pass normalize that decrease the total volume only of all audio past each loudest peak. So if there was a pretty loud noise 15min into a video, it might lower the gain to 0.96, but if later there was an even louder noise it might lower the gain again, e.g. from 0.96 to 0.87.

Dynamic range compression is entirely separate, both of these options do not do any range compression themselves and are only adjusting a global volume gain.

LigH

27th April 2021, 07:30

Normalize matrix is simply changing the weights of a downmix matrix so it is impossible for the downmix to go over 100% in any channel, isn't it? This is always quieter, but will never clip.

I would agree.

mogli

27th April 2021, 08:17

IIRC clipping protection just uses a limiter, i.e. goes down if the volume is too high but quickly goes back to full volume afterwards.

Clipping protection doesn't care what the lowest level is at all, it simply lowers the total volume to prevent clipping anytime the volume goes too high. This has the somewhat odd effect of causing the average volume level to be lower after a loud noise that would have clipped at the previous level. It is like a single pass normalize that decrease the total volume only of all audio past each loudest peak. So if there was a pretty loud noise 15min into a video, it might lower the gain to 0.96, but if later there was an even louder noise it might lower the gain again, e.g. from 0.96 to 0.87.Why would anyone do that? One would eventually end up with the same volume as matrix normalization for most movies but could hear how the volume goes down over the playing time. No benefit at all but very annoying.

nevcairiel

27th April 2021, 11:49

Why would anyone do that? One would eventually end up with the same volume as matrix normalization for most movies

Thats far from the truth. Especially if you don't include LFE in the downmix, as eg. Dolby recommends, most 5.1 streams can be downmixed to stereo without a change in volume, or only a very small one.
Mastering of commercial content rarely maxes out single channel levels.

No benefit at all but very annoying.

You are free to not use it. But given the above reasoning, its a perfectly reasonable experience.

mogli

27th April 2021, 13:25

Mastering of commercial content rarely maxes out single channel levels.We're talking about downmixing so channels will add up and e.g. even overload at half the full volume.

Asmodian

27th April 2021, 17:54

We're talking about downmixing so channels will add up and e.g. even overload at half the full volume.

I often use it for headphones, I very rarely notice the volume decreasing due to a loud noise.

Have you tried it? It isn't a bad experience. You are free to use the normalized matrix option instead too, that is why it exists. :)

nevcairiel

29th April 2021, 10:03

We're talking about downmixing so channels will add up and e.g. even overload at half the full volume.

Good that I explained the line above what you quoted why that isn't a problem in typical content.

Yes, it can theoretically happen that the volume lowers to the same level, however in the real-world with typical consumer-grade content this is not the case.
There are various factors that allow this. As said above already, channels are never maxed out, so there is headroom to do mixing in. Additionally, surround channel are often quieter for a more ambient experience then fronts, and due to the way PCM works, only if the audio is coherent would peaks actually add up perfectly. Additionally, not including LFE enables it to be much more reliable. And of course this only applies to 5.1, if you downmix 7.1 without dropping the rear channel, the chances of running into a volume reduction are much higher.

This is factually a technique used in many downmixing applications to various degrees. Sometimes in a hybrid fashion, where the mixing matrix is reduced so incoherent audio signals will never clip under any circumstances (disregarding existing headroom etc), but a coherent one still would. Preserving volume when downmixing for headphones is important for many users.

It does sound to me like you haven't even tried it, nor fully understood how and why it works.

At the end of the day, I'm not even sure what you are arguing for. This mode has been popular over the various years it has existed. But its also not the only mode you can use. You can just let it overflow (by checking no options), or you can use a fully normalized matrix where clipping is impossible, and handle the reduced volume in other ways. There is also no secret how it works, the potential for sudden volume changtes is even mentioned in the tooltip of the option. If you don't like one particular mode, you can just use another, there is nothing to gain from complaining that it exists and how bad it might be in your eyes.

manolito

29th April 2021, 23:32

nevcairiel

30th April 2021, 13:02

What I do not understand is why the two options "normalize matrix" and "clipping protection" can be ticked at the same time. Since both options should prevent clipping when only one of them is ticked (as Asmodian explained) then in which situation could it be useful to activate both options?

Its not really useful, unless the signal would overflow on its own, which is only really possible with float codecs, so not really a common thing.
I suppose I could've locked the checkbox, but eh, doesn't really change anything.

Sunspark

1st May 2021, 01:47

Its not really useful, unless the signal would overflow on its own, which is only really possible with float codecs, so not really a common thing.
I suppose I could've locked the checkbox, but eh, doesn't really change anything.

A streaming radio station I like, the input states vorbis codec, 32bit Float and the output states PCM codec, 32bit Float. Checked another one, the input codec was aac, but it was also 32bit Float.

Maybe float is more common with streaming radio?

nevcairiel

1st May 2021, 02:02

A streaming radio station I like, the input states vorbis codec, 32bit Float and the output states PCM codec, 32bit Float. Checked another one, the input codec was aac, but it was also 32bit Float.

Maybe float is more common with streaming radio?

Those are just lossy codecs that decode to float, but they wouldn't really overflow.

mogli

2nd May 2021, 10:02

@nevcairiel

I just hope for an improved clipping protection.
If it's overflowing often it can't be helped and the overall volume needs to be decreased permanently for that movie. However, as you said yourself, that's rarely the case. Maybe only a few seconds, miliseconds or even samples overflow in a whole movie. Using a limiter in such a situation would allow to keep the overall volume steady and loud. So essentially I hope for short time (limiting) and long time overshoots (normalization, leveling) to be handled separately.
At 2 minutes in decreasing the volume by 2dB because 2 samples overflowed for the rest of a 2 hour movie doesn't sound reasonable to me.