View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
clsid
25th January 2016, 22:14
That instability (only) occurs when something else is also using CUDA/OpenCL at the same time. For example SVP or certain functionality in madVR (like NNEDI and Error Diffusion). NVIDIA is the one that must fix it.
hu1kamania
26th January 2016, 00:28
That instability (only) occurs when something else is also using CUDA/OpenCL at the same time. For example SVP or certain functionality in madVR (like NNEDI and Error Diffusion). NVIDIA is the one that must fix it.
Thank you for clearing that up. It's a shame that we need to go back to April of last year to find a driver that works. Even worse, the driver doesn't officially support my hardware or OS!
I will have to keep an eye on OpenCL development from Nvidia, which might be about as interesting as watching paint dry. Nvidia never had a very cozy relationship with OpenCL, to my recollection.
rock
26th January 2016, 07:35
sorry, just wanna say thanks for dxva2n fix for old intel gpu (mine is sandy bridge). it fixed playback for my ts file I posted in the past which is actually an interlaced video :)
khanmein
26th January 2016, 14:27
guys, when i tick HEVC on LAV Video Decoder to watch x265 .mkv, it will suddenly freeze or hang if i drag fast forward/backward. i'm using GTX 970 + i5-4460 + DXVA2 (copy-back)
LigH
26th January 2016, 16:10
No surprise. When your player prefers exact seeking, it will have to decode often from the beginning of the GOP you navigated into to the target frame, and because HEVC is very complex, that will take its time (the longer the GOPs may be, the longer the seeking may take). If you can switch to fast seeking, it will seek always to a GOP start instead, that will be faster but rather coarse, you may then only seek each few seconds apart.
clsid
26th January 2016, 16:54
Dragging the seekbar will spawn a lot of seek operations. You will get better response by clicking or using the jump function of the player.
Also, the GTX970 only supports partial acceleration of HEVC. Using software decoding may give better performance.
khanmein
27th January 2016, 10:40
thanks so partially support x265 only? damn~
nevcairiel
27th January 2016, 16:08
As of 0.67.0-67, LAV Video supports a new software deinterlacer, Weston Three Field Deinterlacing Filter (w3fdif)
w3fdif was developed by the BBC, and as I understand it, is also used by them in real-world usage.
w3fdif comes in two variants: Simple and Complex.
The difference is of course the potential quality, but also the speed.
I will let you guys judge its quality in comparison to YADIF (or even hardware deinterlacing), but there is one thing to be said about it: Its fast.
On 32-bit, Simple is significantly faster than YADIF, but due to lack of 32-bit optimizations, Complex is slower.
On 64-bit, both Simple and Complex are faster than YADIF.
Hopefully the SSE2 optimizations for Complex can be made compatible with 32-bit in the future.
A new build is available here now:
https://files.1f0.de/lavf/nightly/
Note that w3fdif does not have an option to control the number of output frames, it will always produce one frame per input field, ie. its always a double rate deinterlacer (the only proper way to deinterlace, anyway!)
PS:
The Software Deinterlacing options section looks a bit crammed, but never mind that, I have some plans to re-do some areas of that entire config screen.
madshi
27th January 2016, 17:16
Interesting! Is there some paper with screenshots or technical description or something about that deinterlacer? Never heard about it yet...
nevcairiel
27th January 2016, 17:21
Interesting! Is there some paper with screenshots or technical description or something about that deinterlacer? Never heard about it yet...
I didn't write it, just use what is in FFmpeg, so..
On a quick search I found its patent entry, which at least explains some things:
http://www.google.com/patents/US4789893#v=onepage&q&f=false
madshi
27th January 2016, 17:31
Ah, I see, thanks!
SamuriHL
27th January 2016, 17:55
That's pretty wild. I think I'll have to try that out on some of my 1080i tivo recordings and see how it looks.
noee
27th January 2016, 18:06
That's pretty wild. I think I'll have to try that out on some of my 1080i tivo recordings and see how it looks.
fwiw, I've been using it for a bit now on some old broadcast videos with generally poor interlaced content and to my eye, it seems on par with yadif (for my settings), but as nev says, it is faster.
I do notice on some scenes with vertical panning, there is a shimmering that occurs on edges here and there that are not as pronounced with yadif.
Be interesting to see what you think.
hu1kamania
27th January 2016, 18:39
How exciting! I can't wait to play around with this. I hope it beats out yadif, and CUVID hardware deinterlacing.
Thank you for the hard work, and innovation. Nevcairiel, you have my eternal respect. Same goes for madshi. Thank you!
sneaker_ger
27th January 2016, 18:44
Not a regression of the new deinterlacer but I think software deinterlacing is broken with 10 bit H.264 files. (picture is black)
nevcairiel
27th January 2016, 18:50
Software deinterlacing only works with 8-bit, always has. Don't encode such crap like 10-bit interlaced. :p
sneaker_ger
27th January 2016, 18:53
Ok, guessed so. I only vaguely recalled this coming up before but didn't find the older posts.
Let's hope they don't combine it in television now that HEVC 10 bit is gaining.
SamuriHL
27th January 2016, 19:34
fwiw, I've been using it for a bit now on some old broadcast videos with generally poor interlaced content and to my eye, it seems on par with yadif (for my settings), but as nev says, it is faster.
I do notice on some scenes with vertical panning, there is a shimmering that occurs on edges here and there that are not as pronounced with yadif.
Be interesting to see what you think.
Thanks for the input. I'll play around with it tonight. I had already updated to the latest nightly for another reason anyway, so, I should be good to go by enabling it.
SamuriHL
27th January 2016, 19:36
Software deinterlacing only works with 8-bit, always has. Don't encode such crap like 10-bit interlaced. :p
What the??? Who in their right mind would encode 10 bit interlaced?! LAMO! *NOT SUPPORTED!* LOL
P.J
27th January 2016, 22:10
Weston Three Field Deinterlacing Filter http://forums.mydigitallife.info/vb4_style/smilies/3eyes.gif
:thanks:
Edit: Any comparison between it and hardware pixel-adaptive?
SamuriHL
28th January 2016, 01:12
Wow, I gotta say, that new deinterlacing is pretty damn sweet. I'm using complex right now. Combined with madvr's reconstruction, my TiVo recordings look incredible. Well done boys! P.S. And DAMN smooth.
burfadel
28th January 2016, 04:54
The nightly builds available from https://files.1f0.de/lavf/nightly/ do not work with the latest Windows Insider preview 14251 released today. It fails with regsvr32 error 0x3.
Even when already installed and Windows is updated, the previously registered files no not work.
However, build LAVFilters-0.65.0-24.exe and older installs and works perfectly, so the issue must be in LAVFilters-0.65.0-25.exe and later. I tried the .zip archive version of 0.67 as well, the files did not register with that either. Maybe there is a compiler issue/reason for it not working?
I'm willing to test different compiles of the latest version to see if the issue is resolved. The issue is probably with the new build of Windows, but at least if the issue is isolated it can be reported correctly through the Windows feedback tool. LAV Filters seems to be the only program affected by it, so simply reporting that LAV Filters doesn't work and the circumstance that the issue not affecting any other program, may mean the issue goes unfixed before Windows 10 Redstone release later this year.
That said, the issue may be with a change introduced with LAVFilters-0.65.0-25.exe that has only become apparent with the latest Windows build. Either way, I'm more than willing to test out different builds!
nevcairiel
28th January 2016, 10:38
0x3 means its missing some dependency (or some function from some dependency), you can use Dependency Walker (http://www.dependencywalker.com/) to check what it may be missing.
That said, I'm not overly concerned with breakage in insider builds, there have been a lot of issues with the recent builds.
0.65.0-25 was a FFmpeg update, so if something changed it would appear to be in there.
MrBonk
28th January 2016, 13:19
I recently started testing using MakeMKV to rip DVDs to watch with better upscaling, but was disappointed in that none of the Deinterlacing, whether yadif or cuvid hardware adaptive (GTX 980 here on W7) seemed to be able to match the PS3's De-interlacing quality.
w3fdif doesn't seem to quite get there yet either.
HW Adaptive DI from Cuvid still seems to work the best.
Images. Same frame
yadif http://u.cubeupload.com/MrBonk/mpchc201601280412047.png
w3fdif http://u.cubeupload.com/MrBonk/mpchc201601280411032.png
HW Adaptive http://u.cubeupload.com/MrBonk/mpchc201601280415355.png
(Ignore glitches/repeated/dropped and render times)
OSD shows DI is off, but I have it set to Force in LAV. Otherwise it doesn't seem to work. It is Interlaced and MediaInfo shows that it is.
nevcairiel
28th January 2016, 13:21
Most deinterlacers are designed for real-life video content, not animation, so they will usually not fare very well on that kind of content (too many sharp edges).
Note that DVDs might also be telecined, not interlaced, which a normal deinterlacer would not handle very well at all.
madshi
28th January 2016, 13:42
You can try forced film mode in madVR, if the DVDs are telecined content.
Magik Mark
28th January 2016, 13:45
I experimented with it by turning off madvr deinterlacer. Image is a lot better. The 32bit really need some optimization though
MrBonk
28th January 2016, 14:03
The content has to be interlaced as using forced film mode(+Film mode deinterlacing) produces even poorer quality and constant judder with any camera movement (Where native 23.976FPS and 29.97 Progressive files and Video mode played back do not)
Screenshot of same frame with forced Film mode and Film yadif
http://u.cubeupload.com/MrBonk/mpchc201601280448566.png
Screenshot forced film mode and film Cuvid HW Adatpive
http://u.cubeupload.com/MrBonk/mpchc201601280452128.png
Turning all deinterlacing off, leaving on auto source detection and using only the "Inverse Telecine" option in NVCP while using Cuvid looks like this
http://u.cubeupload.com/MrBonk/mpchc201601280454457.png
But heavy interlacing and judder are still present in motion
http://u.cubeupload.com/MrBonk/mpchc201601280454508.png
Is re-encoding my only option to fix it really?
I wouldn't mind. Is an encoding solution of higher quality?
madshi
28th January 2016, 14:09
Screenshot of same frame with forced Film mode and Film yadif
Screenshot forced film mode and film Cuvid HW Adatpive
I was talking about forced film mode in madVR. If you want to use that, you have to completely turn off deinterlacing in LAV Video Decoder.
MrBonk
28th January 2016, 14:19
I was talking about forced film mode in madVR. If you want to use that, you have to completely turn off deinterlacing in LAV Video Decoder.
Oh, yes I had that enabled too. But I didn't know you had to disable LAV and it's DI detection and other DI methods off at the same time.
With only that set or video set and DI set to disabled in LAV. Same results. Judder, constant interlacing.
OH:thanks: I have to leave DI set to "Auto" in LAV and leave the other DI in that off and then set force "Film" mode.
And shazam. Works perfectly.
I'm such a dumb dumb.
Thanks a lot!
clsid
28th January 2016, 19:32
0x3 means its missing some dependency (or some function from some dependency), you can use Dependency Walker (http://www.dependencywalker.com/) to check what it may be missing.
That said, I'm not overly concerned with breakage in insider builds, there have been a lot of issues with the recent builds.
0.65.0-25 was a FFmpeg update, so if something changed it would appear to be in there.
Looking at the dates of those build, I think you also updated from GCC 4.9.3 to a 5.1 toolchain.
The error appears to be related to failing to load API-MS-WIN-*.DLL files.
nevcairiel
28th January 2016, 20:00
Never mind those, only direct dependencies of LAV or the FFmpeg dlls are of relevance, those MS things always show up one or two levels down.
KoD
28th January 2016, 20:57
I think I noticed in the commit logs that files which have fps outside some arbitrary magic values will be considered "corrupt". I don't think this is a good idea. If someone has a recording made with a high speed camera, he will encounter issues when trying to play it, and not because the file has a problem, but because the decoder (or was it the splitter?) has a if "fps < 125" then be nice otherwise claim file is bad. Also, the case I keep on making that one can make a mkv of 1 hour with only one or two frames in it would become impossible to play when having a limit on how low the fps is allowed to be. What I am trying to say is that if a container spec says that such files are supported, they should be supported by lav as well.
nevcairiel
28th January 2016, 23:34
Files with "uncommon" FPS will not stop it from playing. There is just a heuristic in place to try to select the most logical FPS to offer up as metadata. Any "FPS" values are unreliable anyway, the real determining fact is the timestamps of the video frames.
r4dius
29th January 2016, 00:31
The nightly builds available from https://files.1f0.de/lavf/nightly/ do not work with the latest Windows Insider preview 14251 released today. It fails with regsvr32 error 0x3.
Even when already installed and Windows is updated, the previously registered files no not work.
However, build LAVFilters-0.65.0-24.exe and older installs and works perfectly, so the issue must be in LAVFilters-0.65.0-25.exe and later. I tried the .zip archive version of 0.67 as well, the files did not register with that either. Maybe there is a compiler issue/reason for it not working?
I'm willing to test different compiles of the latest version to see if the issue is resolved. The issue is probably with the new build of Windows, but at least if the issue is isolated it can be reported correctly through the Windows feedback tool. LAV Filters seems to be the only program affected by it, so simply reporting that LAV Filters doesn't work and the circumstance that the issue not affecting any other program, may mean the issue goes unfixed before Windows 10 Redstone release later this year.
That said, the issue may be with a change introduced with LAVFilters-0.65.0-25.exe that has only become apparent with the latest Windows build. Either way, I'm more than willing to test out different builds!
Thanks for you analyse, I installed 0.64.0-24 until some other fix :)
hu1kamania
29th January 2016, 00:42
I have some questions and comments in regards to CUVID. I don't post often, but I've been reading Doom9 for many years. Over the last couple years I've noticed a trend to wean people off the usage of CUVID.
I understand there are a lot of con's in regards to CUVID. Many are illustrated in this post at the jriver forums: https://yabb.jriver.com/interact/index.php?topic=80258.0 though some concerns seem unfounded.
More recently it seems to be broken in Windows 10, unless you are running CUDA 7.0.0 or older. Thanks to clsid for expanding on an previous post as to why that is.
Are we shying away from CUVID because we won't trust NVIDIA to reliably support it on their end? After all, it takes some less than ideal measures to get it working with Windows 10. The driver that "works" was designed for Windows 8.1 and dates back to April of last year!
Is the move away from CUVID because DXVA support is more universal? As in, if development time is put towards DXVA, it should benefit AMD as well as NVIDIA users?
I realize I probably answered my own questions, but I'm asking because image quality is king for me, and I find CUVID's hardware deinterlacing to be best for real time playback. If I thought CUVID support was at an end, or likely at an end, I might be persuaded to compromise and learn to live with yadif/w3fdif. MadVR's DXVA hardware deinterlacing doesn't cut it right now, but I have faith madshi will get it there eventually. At this point in time, is it safe to say CUVID's place in LAV Filter's is purely a legacy one? An explanation beyond: "forget CUVID plz... (http://forum.doom9.org/showpost.php?p=1755170&postcount=35696)" would be appreciated.
Thanks!
clsid
29th January 2016, 00:56
Regarding the Win10 Build 14251 problems:
Faulting application name: regsvr32.exe, version: 10.0.14251.1000, time stamp: 0x56a53e57
Faulting module name: avcodec-lav-57.dll, version: 57.22.101.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x0076d5d2
0.67.0-67 x86
foxyshadis
29th January 2016, 01:31
Are we shying away from CUVID because we won't trust NVIDIA to reliably support it on their end? After all, it takes some less than ideal measures to get it working with Windows 10. The driver that "works" was designed for Windows 8.1 and dates back to April of last year!
The pressure to abandon CUVID is because CUVID appears to be abandoned and no reassurance has come from nvidia that it will ever be actively supported again. They haven't announced that it'll ever be available for win10, or that it'll be supported going forward. It's not terribly surprising that it's still present a recent 8.1 driver, since it's relatively unchanged from the original win8 CUVID support since early 2013; no work on their part to keep it in. Notably, although it's still bundled into drivers, no new formats have been supported, no bugs have been fixed in a year, new bugs have appeared. Instead, nvidia turned on the CUVID processing (deinterlacing and sharpening) on their DXVA2 decoder in the last year or two, so what's the point of not using DVXA now?
I haven't tested on my win10 system, but on my 8.1 the deinterlacing quality seems to be the same in CUVID or DXVA mode. Are there specific differences you're seeing?
huhn
29th January 2016, 01:32
I have some questions and comments in regards to CUVID. I don't post often, but I've been reading Doom9 for many years. Over the last couple years I've noticed a trend to wean people off the usage of CUVID.
I understand there are a lot of con's in regards to CUVID. Many are illustrated in this post at the jriver forums: https://yabb.jriver.com/interact/index.php?topic=80258.0 though some concerns seem unfounded.
More recently it seems to be broken in Windows 10, unless you are running CUDA 7.0.0 or older. Thanks to clsid for expanding on an previous post as to why that is.
Are we shying away from CUVID because we won't trust NVIDIA to reliably support it on their end? After all, it takes some less than ideal measures to get it working with Windows 10. The driver that "works" was designed for Windows 8.1 and dates back to April of last year!
Is the move away from CUVID because DXVA support is more universal? As in, if development time is put towards DXVA, it should benefit AMD as well as NVIDIA users?
I realize I probably answered my own questions, but I'm asking because image quality is king for me, and I find CUVID's hardware deinterlacing to be best for real time playback. If I thought CUVID support was at an end, or likely at an end, I might be persuaded to compromise and learn to live with yadif/w3fdif. MadVR's DXVA hardware deinterlacing doesn't cut it right now, but I have faith madshi will get it there eventually. At this point in time, is it safe to say CUVID's place in LAV Filter's is purely a legacy one? An explanation beyond: "forget CUVID plz... (http://forum.doom9.org/showpost.php?p=1755170&postcount=35696)" would be appreciated.
Thanks!
this thread is a way better place to talk about this than the madVR thread.
you are saying madVR DXVA doesn't cut it for you right now.
but it should be the same as CUVID deinterlacing and it all my test it is the same.
so a sample or something that will show the difference between DXVA deinterlancing and CUVID deinterlancing would be really nice!
general CUVID bug/limitations:
windows 10 bug:
CUVID and running any other openCL program will stop CUVID from delivering frames to the renderer.
limitation:
CUVID doesn't support 10 bit output so it can't be used for 10 bit HEVC.
the used decoder/deinterlancer shouldn't be any different from DXVA. why should nvidia write different deintelrancer for DXVA and CUVID that would be a huge waste of money.
nevcairiel
29th January 2016, 01:34
Note that deinterlacing through CUVID on Windows 10 may also be slightly lower quality than it is on Windows 7/8.1, because the Direct3D interop stopped functioning, which was previously required to obtain full quality.
huhn
29th January 2016, 01:38
getting better and better...
biship
29th January 2016, 01:54
The nightly builds available from https://files.1f0.de/lavf/nightly/ do not work with the latest Windows Insider preview 14251 released today. It fails with regsvr32 error 0x3.
However, build LAVFilters-0.65.0-24.exe and older installs and works perfectly, so the issue must be in LAVFilters-0.65.0-25.exe and later
Yup, same problem. I had to go back to LAVFilters-0.65.0-24.exe. Thanks for finding the fix!
nevcairiel
29th January 2016, 01:58
Report it to Microsoft instead. Their insider builds have been rather broken as of late.
burfadel
29th January 2016, 05:09
For everyone with the 0x3 error installing the LAV Filters (post-version I mentioned earlier of course).
Open this link in Microsoft Edge browser:
Windows-Feedback:?contextid=156&feedbackid=9a9f3867-6e6d-439d-a5ed-d8006d050268&form=1&src=2
If using Chrome, Firefox, or other browser just copy and paste it into Edge.
This will take you directly to a feedback someone (not me) has given regarding this issue. Apparently other programs are also affected.
Upvote way! The more upvotes the better :).
hu1kamania
29th January 2016, 20:21
The pressure to abandon CUVID is because CUVID appears to be abandoned and no reassurance has come from nvidia that it will ever be actively supported again.
Thank you for expanding on the situation with Nvidia. It certainly looks like CUVID is in fact abandoned, and their intent is to have DXVA2 take it's place.
I haven't tested on my win10 system, but on my 8.1 the deinterlacing quality seems to be the same in CUVID or DXVA mode. Are there specific differences you're seeing?
you are saying madVR DXVA doesn't cut it for you right now.
but it should be the same as CUVID deinterlacing and it all my test it is the same.
so a sample or something that will show the difference between DXVA deinterlancing and CUVID deinterlancing would be really nice!
I follow what you're saying huhn, but I am definitely seeing a difference!
In Windows 8.1 I did not see a difference between MadVR and CUVID, but I found the quality to be lacking, so I stuck with yadif + DXVA copy-back. After switching to W10 and experiencing the bug related to CUVID I eventually came across the solution I explained a few posts back. With the older 350.12 driver I saw a big improvement in quality with CUVID based deinterlacing.
The interlaced content I watch most is broadcast NTSC, so 480i/30, 720i/30, and 1080i/30 as well as some 480i/30 DVDs. With MadVR's hardware deinterlacing, I see more shimmer/aliasing when compared to CUVID or yadif.
One channel in particular runs at 480i/30 and has a static watermark that flickers constantly with MadVR. Forcing film mode helps with the watermark flicker, but I get a lot of jerky movement. Yadif/w3fdif helps, but CUVID + 350.12 driver completely eliminates the flicker. I do see a bit more aliasing on sharp edges with w3fdif, so yadif is my favorite between the two (I want to test that more this weekend, I'm writing this from work :eek: )
Note that deinterlacing through CUVID on Windows 10 may also be slightly lower quality than it is on Windows 7/8.1, because the Direct3D interop stopped functioning, which was previously required to obtain full quality.
Making my claims appear all the more lofty, I know!
Mixer73
30th January 2016, 14:23
One channel in particular runs at 480i/30 and has a static watermark that flickers constantly with MadVR. Forcing film mode helps with the watermark flicker, but I get a lot of jerky movement. Yadif/w3fdif helps, but CUVID + 350.12 driver completely eliminates the flicker. I do see a bit more aliasing on sharp edges with w3fdif, so yadif is my favorite between the two (I want to test that more this weekend, I'm writing this from work :eek: )
I'd be prepared to bet this content is actually shot progressive, but transmitted in interlaced, with the bug added, so it is actually mixed content.
KoD
30th January 2016, 18:16
Hi nevcariel. I have an audio-related issue which I suspect is due to lav audio.
With this sample (http://wikisend.com/download/925408/WaveOut_TrueHD.mkv) [25Mb], when using any of the DirectSound options or the sanear audio renderer in a media player, the sound is ok. However, trying to use any of the wave out audio renderers, has as effect a garbled sound, as if it's coming from under water. I get the same behavior using either MPC-HC or ZoomPlayer, and the video renderer does not matter. Only the audio renderer matters. VLC plays this file with any audio renderer (the wave out too) just fine. What's interesting is that VLC says the audio is TrueHD 48Khz 32 bit per sample, while Lav audio says it's 24 bit integer per sample. Lav outputs 24 bit integers too. Btw, I have only stereo audio devices which don't know to handle 32 bit output, only up to 24 bit, but this should not matter, right? I mean, even when lav outputs 6 channel 32 bit float with other files, wave out still works.
Lav audio plays without issue with the direct sound renderers, and its status says the same thing, that the audio samples are 24 bit integer, and that it outputs 24 bit integers.
This behavior is not new, it has been like this with the lav filters since forever, but I decided to finally make it known.
nevcairiel
30th January 2016, 18:30
Sounds like your downmixing is just not working properly in all cases, for consistent output you could just let LAV downmix to stereo instead of relying on the OS. WaveOut probably relies on the audio driver to downmix, while DirectSound uses the DS audio mixer.
Why do you want to use WaveOut anyway? DirectSound should generally be superior.
KoD
30th January 2016, 18:37
Hi nev, the issue is the same when activating downmixing in lav audio to stereo. It's not a downmixing issue, it's a misdetection of the file format issue, or maybe sending the data out to the renderer with bad headers or something. (I was sure you were going to try and get the easy way out by blaming this... how about testing the file first?)
nevcairiel
30th January 2016, 18:38
Hi nev, the issue is the same when activating downmixing in lav audio to stereo. It's not a downmixing issue, it's a misdetection of the file format issue, or maybe sending the data out to the renderer with bad headers or something.
Sounds more like your renderer doesn't like 24-bit audio then, which you can also turn off in LAV for testing. All output modes have been well tested over years of usage, and clearly its not a decoding problem otherwise it would sound bad everywhere, and clearly its not a generic 24-bit output problem or it would also sound bad everywhere, so that leaves me to conclude that your audio renderer doesn't like something it produces, that leaves either downmixing or 24-bit. And since WaveOut is controlled by the audio driver, thats usually the case.
This theory is easy to test, just force other files that generally work to 24-bit output using the LAV options, and see if they now also sound bad.
LAV doesn't behave differently depending on what kind of audio renderer it interfaces with, and if the status page is exactly the same as you say, then it also behaves exactly the same. When one audio renderer fails and the other works on the same audio, why do you search the problem with the decoder in the first place?
(I was sure you were going to try and get the easy way out by blaming this...)
The easiest solution is often the correct one.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.