LAV Filters - DirectShow Media Splitter and Decoders

[omarank]

Hi 6233638, do you mean to say that the new resampler in ReClock doesn't bypass any nastiness by the audio drivers in WASAPI? Also, from where can I get this old resampler of ReClock, for testing purposes? I wanted to know that if I am using WASAPI exclusive mode in ReClock, do I need to care about that Windows hotfix for audio resampler?

[6233638]

Originally Posted by omarank

Hi 6233638, do you mean to say that the new resampler in ReClock doesn't bypass any nastiness by the audio drivers in WASAPI? Also, from where can I get this old resampler of ReClock, for testing purposes? I wanted to know that if I am using WASAPI exclusive mode in ReClock, do I need to care about that Windows hotfix for audio resampler?

WASAPI alone should bypass any potentially bad conversions going on inside the driver I think, because it does not allow higher sample rates than the card can natively accept.

With DirectSound output, three different drivers gave me the options of 24-bit, 24-bit padded, 32-bit int, and 32-bit float as the best options it would accept.
With WASAPI, the card will only accept 24-bit padded to 32-bit, regardless of the driver installed, it rejects 24-bit and 32-bit int/float.

So I have to assume that when using DirectSound with the newer drivers, it's performing a conversion from 32-bit int/float to 24-bit, and I don't know how good/bad that may be. I don't know if that's done using the Windows resampler, or some code in the driver itself though.

WASAPI just seems to bypass the potential for problems.



If you are using WASAPI output, Windows will not be doing any resampling, so you don't need to worry about that hotfix. I don't know if the hotfix even applies to the resampler that would be used if you are using DirectSound out either. (but it can't hurt to have it installed)


This is the resampler dll I used for Reclock: http://www.datafilehost.com/download-7089655d.html
I don't know if it was compiled with optimisations enabled though, so in addition to using a more CPU intensive resampler (SRC) it may require even more CPU as a result of that. (I don't know if anyone has a dll compiled with optimisations)

You will have to open up the Reclock preferences again and re-select "best sinc interpolator" when you change the dll.


I don't know how SRC (and it's an older build of SRC at this point) compares to the Windows DirectSound mixer, or the newer resampler that now ships with Reclock. It was my understanding that the newer resampler for reclock was focused on reducing CPU usage, rather than necessarily being focused on the best audio quality at all costs. It's been a few years at this point now (reclock development seems to have stopped) so I don't remember the specifics and I could be mistaken.

Perhaps someone else could clarify this. (and if someone has compiled a more optimised dll using the latest SRC code, I'd appreciate the link)

[madshi]

SRC etc are samplerate converters. They are not bitdepth converters. That are 2 totally different things. Converting samplerate well is very very difficult and complex. Converting bitdepth is dead easy in comparison. What we were talking about in this thread (dithering needed when doing bitdepth reduction etc) has nothing to do with samplerate conversion at all. I don't think LAV Filter ever does any samplerate conversion, so discussion about samplerate converters doesn't really belong into this thread.

[Pomegranate]

Madshi, if one starts with a lossy audio file and it is decoded to 32 bit fp, is there any audible difference between

a) the 32-bit fp representation and
b) taking the 32-bit fp and reducing the bit depth to 24 bit integer, with or without dithering.

I can't seem to get a straight answer on this

[nevcairiel]

For the record, if your audio driver is doing terrible things, WASAPI won't stop it from doing them. But in general, on Windows 7, all audio processing is done by DirectSound/Windows Audio, and not left to the driver anymore, which should give you at least a somewhat consistent image of what happens, independent of driver quirks.
Thats the biggest difference to XP, where the driver itself had to convert to a hardware format, and in Vista/7, this is done by the OS.

[nevcairiel]

Originally Posted by Pomegranate

Madshi, if one starts with a lossy audio file and it is decoded to 32 bit fp, is there any audible difference between

a) the 32-bit fp representation and
b) taking the 32-bit fp and reducing the bit depth to 24 bit integer, with or without dithering.

I can't seem to get a straight answer on this

Audible in 24-bit, probably not, unless you have audio in *very* low volumes (32fp can better represent very low volumes than integer can) - like volume constantly below 5%, otherwise any rounding issues vanish in the inaudible parts. Heck most DACs only do 19-20 bits.

[Pomegranate]

Originally Posted by nevcairiel

Audible in 24-bit, probably not, unless you have audio in *very* low volumes (32fp can better represent very low volumes than integer can) - like volume constantly below 5%, otherwise any rounding issues vanish in the inaudible parts. Heck most DACs only do 19-20 bits.

Thank you very much for the clarification, kind sir.

So, for the majority of lossy encoded material comercially available, I'm perfectly fine with 32-bit fp to 24 bit int done inside LAV audio, while using kernel streaming?

[6233638]

Originally Posted by madshi

SRC etc are samplerate converters. They are not bitdepth converters. That are 2 totally different things. Converting samplerate well is very very difficult and complex. Converting bitdepth is dead easy in comparison. What we were talking about in this thread (dithering needed when doing bitdepth reduction etc) has nothing to do with samplerate conversion at all. I don't think LAV Filter ever does any samplerate conversion, so discussion about samplerate converters doesn't really belong into this thread.

Well that was maybe a bad example. Changing drivers would also let my card accept up to 192kHz, when it only supports up to 48kHz over WASAPI.

It sounds like that conversion would have been handled by the Windows mixer rather than the drivers though, which doesn't seem to be a bad thing from the sound of it. I was more concerned that it was being done by the drivers, and who knows what could have been going on there.


For what it's worth, I've just done some testing in Windows 8, and neither DirectSound or the old/new Reclock resamplers have aliasing problems. (as long as you are using Sinc in Reclock) From doing more reading, it looks like only WaveOut from Reclock would have been affected by the aliasing problems that hotfix was for.

The new Reclock resampler did have audible problems when downsampling 96kHz audio to 48 though. Both DirectSound and the old Reclock resampler were fine. (stayed silent once the sweep got above my threshold of hearing)

[nevcairiel]

Originally Posted by Pomegranate

So, for the majority of lossy encoded material comercially available, I'm perfectly fine with 32-bit fp to 24 bit int done inside LAV audio, while using kernel streaming?

Should be just fine. The next major release will most likely also include optional dithering.

[Pomegranate]

^ Cherry on top of the cake, good sir!

[omarank]

Originally Posted by 6233638

This is the resampler dll I used for Reclock: http://www.datafilehost.com/download-7089655d.html

Thanks. I wish ReClock development hadn't stopped.

[Brom]

Originally Posted by nevcairiel

For the record, if your audio driver is doing terrible things, WASAPI won't stop it from doing them. But in general, on Windows 7, all audio processing is done by DirectSound/Windows Audio, and not left to the driver anymore, which should give you at least a somewhat consistent image of what happens, independent of driver quirks.
Thats the biggest difference to XP, where the driver itself had to convert to a hardware format, and in Vista/7, this is done by the OS.

How can you test if your driver is doing terrible things?

Under Win7 (i guess it started with Vista?) can you bitexactly stream the LPCM from the decoder (configured like that) or is there still some processing by DirectSound/Windows Audio?

[Qaq]

Originally Posted by nevcairiel

The next major release will most likely also include optional dithering.

That would be great. At least for perfectly matched sources (MezzoHD 1080i50 for example) I could set ReClock to "original speed".

[6233638]

Originally Posted by Qaq

That would be great. At least for perfectly matched sources (MezzoHD 1080i50 for example) I could set ReClock to "original speed".

Video framerate is never going to be a perfect match to your refresh rate.

ReClock should always be left at "Auto (best)" (note the speed it reports below that is not accurate - it's a bug that was never fixed)

And you should never use the "slave reference clock to audio" option.

[mark0077]

I disagree with using reclock. In both windows 7 and 8 reclock has never been reliable at detecting my displays refresh rate. Especially now in windows 8 where it detects 60.000 hZ when it's actually 59.94 hZ. This completely defeats the purpose if you ask me. So I personally recommend staying away from any of its auto settings. I only use it for wasapi now and try to simply get my display as close to content as possible.

[Qaq]

Originally Posted by 6233638

Video framerate is never going to be a perfect match to your refresh rate.

Just tried MezzoHD 1080i50 on 50Hz display with ReClock "auto". ReClock changed (very rare) 48000Hz from 47999 to 48001. Isn't it perfectly matched?

[mrchisholm]

a some what odd question perhaps but it's been bugging me for a while .. i'm streaming a transponder from TSReader to MPC-HC using LAV filters (splitter/video/audio) and i don't know if it's the issue with MPC or LAV filters or anything else but i have the same problem using graphedit and lav filters.

Problem is that when you start streaming a file is created in temporary internet files called 127_0_0_1[1] or similar (yes i'm streaming to the same PC) and the file seem to grow as the video is fed but when it hits 4GB the streams grinds to a halt. no errors, just stops (or well it seems like it actually restarts playing from where u started the stream when the file reaches 4GB).

I've tried streaming from TSReader to VLC and it does not seem to have this issue. I tried using other splitters in MPC but none of them seem to open the stream so i can't troubleshoot more with MPC.

I guess id just like to know if it at all could be a cause with LAV filters or if i need to go to TSreader devs to solve this problem.

EDIT: tried streaming from dvbviewer and it has the same issue as TSReader so that does not seem to be the cause of the problem.

[ElBarto81]

Hi, I would like to report an issue when using the LAV splitter (version 0.54.1) to play an FLV file. Video stream is H264, audio stream is Nellymoser, both of which get decoded by FFDShow.

When playing the FLV file in Media Player Classic (or any other DirectShow player), I don't get any audio. It looks like the splitter doesn't even detect the audio stream. If I use another splitter (Flash Video Splitter), the audio stream does get detected, but then there's no working playback/seeking: I only see the first frame and position stays at 0:00. Video playback/seeking works perfectly with the LAV splitter.

I'm willing to PM a download link to the FLV file if necessary.

[filler56789]

Originally Posted by ElBarto81

Hi, I would like to report an issue when using the LAV splitter (version 0.54.1) to play an FLV file. Video stream is H264, audio stream is Nellymoser, both of which get decoded by FFDShow.

When playing the FLV file in Media Player Classic (or any other DirectShow player), I don't get any audio. It looks like the splitter doesn't even detect the audio stream. If I use another splitter (Flash Video Splitter), the audio stream does get detected, but then there's no working playback/seeking: I only see the first frame and position stays at 0:00. Video playback/seeking works perfectly with the LAV splitter.

Sounds like you've got an improperly-muxed file
(but I can be wrong).

[nevcairiel]

Originally Posted by ElBarto81

I'm willing to PM a download link to the FLV file if necessary.

That would be the only way to get the details i need.