LAV Filters - DirectShow Media Splitter and Decoders

[CiNcH]

Hi CiNcH! I don't have this problem here, just checked it with Illuminati. Do you use one of the latest ffdshow builds where nevcairiel provided a patch for crashes in H.264 DXVA playback? Even build 3878 was instable, it always crashed at the same playback position of a special movie. With build 3882 this was gone. (and i compiled my own build right after nev's fix, this was also stable)
I see. I am using latest ICL build 3853 by clsid. Think I will switch to the generic builds then. I just had the problem that DVBViewer always crashed when trying to resume the movie. Only after resetting position to 0 it worked again. Thought this could be due to seamless branching and a seeking error. Guess I will have to do more serious testing on this issue then, this time with latest ffdshow build however.

[Johan76]

You could try to update your audio drivers. Wich OS are you running? Since Vista, audio conversions are done by CPU, so windows will convert the formats. In XP a driver update might also add CPU conversion of float to integer.

My HTPC is on WinXP.
Not sure if there are any updated drivers.
I can look but it is always hard to find good drivers for such old hardware.

But since I have a "new" GPU which handles even bluray material I see no point in buying new hardware just because... :)

I will look for newer driver.

BloodySword> Thanks for reclock tips. I will consider. However I cannot use this if it will mess with the bitstreaming.

[ney2x]

ney2x,
if you do insist on using DirectVobSub instead of FFDShow subtitles (either in the decoder or in the separate filter) you can try the option "Vertical padding" in VobSub's General tab. I remember I used it a long time ago but I think it's broken in the latest versions - not sure.

Yeah, I'm completely getting rid of ffdshow and I'll be using LAV Suite (CUVID/Filter). Anyways, my problem solved today, by adjusting the vertical placement and unchecking "Positions subtitle relative to the video frame"

http://img864.imageshack.us/img864/659/mpcj.th.jpg (http://imageshack.us/photo/my-images/864/mpcj.jpg/)

http://img838.imageshack.us/img838/2518/mpc2.th.jpg (http://imageshack.us/photo/my-images/838/mpc2.jpg/)

And also I am using DirectVobSub v2.40.3164 (http://xhmikosr.1f0.de/index.php?folder=bXBjLWhjL21wYy1oY19hcHBzL3ZzZmlsdGVy) . Oh! The reason I used separate subtitle filter is because I also used Windows Media Center (Windows 7 x64).

[Mercury_22]

Yeah, I'm completely getting rid of ffdshow and I'll be using LAV Suite (CUVID/Filter). Anyways, my problem solved today, by adjusting the vertical placement and unchecking "Positions subtitle relative to the video frame"

http://img864.imageshack.us/img864/659/mpcj.th.jpg (http://imageshack.us/photo/my-images/864/mpcj.jpg/)

http://img838.imageshack.us/img838/2518/mpc2.th.jpg (http://imageshack.us/photo/my-images/838/mpc2.jpg/)

And also I am using DirectVobSub v2.40.3164 (http://xhmikosr.1f0.de/index.php?folder=bXBjLWhjL21wYy1oY19hcHBzL3ZzZmlsdGVy) . Oh! The reason I used separate subtitle filter is because I also used Windows Media Center (Windows 7 x64).

You can also use MPC-HC as default player in "Windows Media Center (Windows 7 x64)" (http://mikinho.com/wmc/open-with/) and you'll not need any other filters :)

[clsid]

if you do insist on using DirectVobSub instead of FFDShow subtitles (either in the decoder or in the separate filter) you can try the option "Vertical padding" in VobSub's General tab. I remember I used it a long time ago but I think it's broken in the latest versions - not sure.Vertical padding has been broken for quite some time now. If someone can narrow down the range of revisions in which it got broken, it would increase the chance of a quick fix. So if anyone is bored and wants to do some testing, please do!

[ney2x]

You can also use MPC-HC as default player in "Windows Media Center (Windows 7 x64)" (http://mikinho.com/wmc/open-with/) and you'll not need any other filters :)

Oh well! I ask for 1 help and here you come you help me more... :D That's why I love doom9 :p

Vertical padding has been broken for quite some time now. If someone can narrow down the range of revisions in which it got broken, it would increase the chance of a quick fix. So if anyone is bored and wants to do some testing, please do!

Do you know a site to where I can download different revisions of VSFilter.dll only? Cause I can't parallel download here (http://www.xvidvideo.ru)

Edit: Upon thorough testing different revisions I managed to find the last working "vertical padding" which is DirectVobSub v2.40.2.3104_x86 (http://www.mediafire.com/?1el194y25jbut95) and from DirectVobSub v2.40.2.3112 onwards are broken. FYI.

Question:
Is CCCP Project (http://www.cccp-project.net/beta/) related to MPC-HC Team? Cause I just found out awhile ago that their revisions of VSFilter are not broken.

[clsid]

Are you sure 3104 is working? Because afaik it was broken long before that.

CCCP probably has some custom code. Perhaps they have already located the bug.

[Johan76]

Tried with reclock to convert to 16 bit integer. Kind of work. Sound is good but I get other problems. Easier for me to stick with ffdshow for now.

Sent from my HTC Desire using Tapatalk

[ney2x]

Are you sure 3104 is working? Because afaik it was broken long before that.

CCCP probably has some custom code. Perhaps they have already located the bug.

http://img545.imageshack.us/img545/1623/vobsub.th.jpg (http://imageshack.us/photo/my-images/545/vobsub.jpg/)

But the problem with 3104 is it stays in my system tray and consuming memory even after exiting the player.

And also I want to report the latest revision DirectVobSub v2.40.3237 (http://xhmikosr.1f0.de/index.php?folder=bXBjLWhjL21wYy1oY19hcHBzL3ZzZmlsdGVy) still broken. I thought someone fixed it but still a no go...

This maybe my last post regarding DirectVobSub cause this is OFF-TOPIC. Thanks for your time.

[Gleb Egorych]

*OFFTOPIC*
I'm using Zoom Player and neither 3042 nor 3104 works as expected with vertical padding. Version from CCCP works but there is a problem with aspect ratio on files wider than 16:9 (I use 16:9 extension).

EDIT: problem with aspect ratio was pure ZP problem, solved. As I understand CCCP custom patches only revert particular MPC-HC revisions, 339 and 1096 to be exact.
Sorry for offtopic.
*OFFTOPIC*

[Portioli]

may i ask you sth?
if i have LAV FILTERS in wmp & w7mc(using codec tweak tool) the only way to have external subs is using ffdhow?

[Thunderbolt8]

DirectVobSub v2.40.3237 still broken. I thought someone fixed it but still a no go...OT, but +1.
has already been like that with .2995 (and maybe also before).

[Rectal Prolapse]

Hello! I would like to confirm if LAV Audio + ARCSoft decoder will properly decode DTS-HD Master Audio. Will it do this losslessly or will it only decode the DTS core? I tried searching the thread but could not confirm.

Thanks!

[SamuriHL]

Lossless.

[Portioli]

the best way to have lossless DTS-HD MA with the exact same sample size & sample rate happens with lav audio and the dtsdecoderdll.dll using reclock in wasapi exclusive

http://i.imgur.com/56TOf.jpg

[Gleb Egorych]

Portioli, your screenshot shows that you don't have lossless and exact sample rate because ReClock definitely resamples on your screenshot. It sends bit exact resampled audio not source audio.

[Gleb Egorych]

I tested 5 different versions of dtsdecoderdll.dll along with LAV Audio, here are results.

Versions tested: 1.1.0.0, .1, .5, .7, .8.

Samples tested:
1) Lossy DTS 2.0, 2.1, 5.1, 6.0, 6.1 configs, 16/48, 24/48 and 24/96 bitdepth/sample rate;
2) DTS-MA 1.0, 2.0, 2.1, 5.1, 6.1, 7.1 configs including 7.1 "strange setup" config (eac3to term), 16/48, 24/48, 24/96 variants.
My results differ from results that some people posted in eac3to thread, I guess there may be some eac3to specific problems.

lossy DTS
1) 1.1.0.0 and 1.1.0.1 always decode lossy DTS as 24 bit, and their decoding results differ from each other.
2) 1.1.0.5 and up decode in proper bitdepth.
3) Versions 1.1.0.5 and up decode lossy DTS identically.
4) 1.1.0.1 and 1.1.0.5 decode 24 bit lossy DTS identically.
5) Decoding of 16 bit lossy DTS was changed from 1.1.0.0 to 1.1.0.1 and from 1.1.0.1 to 1.1.0.5.
6) 1.1.0.7 and 1.1.0.8 decode 6.0 without back center channel.

The conclusion for lossy: I assume the best version for lossy DTS is 1.1.0.5. It decodes all configurations I've tested, in proper bitdepth, and decoding algorithm didn't change since this version (except 6.0 bug in .7 and .8).

DTS-MA
All versions output identical streams except mono case. Mono decoding was broken in 1.1.0.5 and partially fixed in 1.1.0.8 (outputs as stereo). Note that MA 7.1 16/48 "strange setup" is decoded as 24/48 by all versions.

The conclusion for lossless: the best versions are 1.1.0.0 and 1.1.0.1.

Of course, to be sure that decoding is done properly some "reference proper" decoder is needed. I don't have it.

EDIT: Forgot to mention about 2.1 bug. None of the versions can decode LFE channel in 2.1 files.

[nevcairiel]

"Lossy" codecs do not have a "proper" bitdepth, in a perfect world it would output floating point data as the ffmpeg decoder does.
Because the process is lossy, there won't be an "accurate" result, different decoders produce different results (most likely), and most decoders also decode to floating point .. ArcSoft is most likely just cutting/rounding to the bitdepth of the source material.

Unless you mean that its outputting 24-bit samples which only have 16bit filled? (Which i've seen before as well - but i may be able to influence that from the outside actually)

Regarding the "reference proper", over in the eac3to thread, some people compared output to the nero and sonic decoders, and apparently only the newer version of the ArcSoft decoder match the output of those two (which is otherwise identical) - on lossless DTS-HD MA only, of course, comparing bit-exactness of lossy is pointless.

[Portioli]

Dts hd - ma is a codec. As long as we have a non hd audio capable receiver we cannot bitstream.
So our goal is the player ( pc+ audio filter ) to decode this codec and send multi-Chanel PCM to our receiver if it has hdmi ( or analog)
if these PCM tracks have the same sample size and same samplerate why this process is not lossless as long as PCM Is set : wasapi exclusive & PCM output's sampling rate is set same as input.
I am talking only for lossless and not bit perfect.
What's the difference of using wasapi for flac files?

[e-t172]

Resampling with Reclock is not lossless. It is very close to being lossless (so close the difference is probably inaudible) but it is not lossless.

If you want lossless bit-perfect sound you need to disable Reclock's time correction ("slave" option). But, obviously, the downside is you'll probably have some frame drops/repeats if you do that. So it's a compromise. Most people prefer to let Reclock resample because the effects on the audio are negligeable, whereas a frame drop/repeat can be quite noticeable.

Also, according to some people, speeding up and resampling from 23.97 fps to 24 fps is, in fact, the Right Thing to Do.

[dbone1026]

OK, just did a clean reinstall of W7 on my PC. Installed LAV splitter, I can't remember, how do I get into the options for LAV? I have the LAV Splitter set up on MPC HC as my external filter (preferred), just can't remember how I used to get into the LAV settings (i.e. to enable forced subs)

[SamuriHL]

LOL. Run a video, right click go to filters, and you should be able to get to the properties there. :)

[dbone1026]

LOL. Run a video, right click go to filters, and you should be able to get to the properties there. :)

yeah that is what i thought. i will have to try again, my head has been in the clouds of late!

[Andy o]

If upsampling makes audio not "lossless", then the audio is never lossless, because the DACs upsample anyway. You need to define what you're "losing" here. Lossless codecs remain without "loss" until the decoding part. Then people usually have no qualms in messing with it via EQ, DSP, room correction, etc. If you don't then your speakers and room will inevitably mess with it for the worse. I see ReClock as just one more of those processing steps. You're not losing sound quality, so does it matter? You're gaining smooth playback (if you have Intel, I would say ReClock is essential), it's not like you're just doing it for kicks.

[robpdotcom]

yeah that is what i thought. i will have to try again, my head has been in the clouds of late!

You can also double click LAVSplitter in the MPC-HC external filters list.

[SamuriHL]

You can also double click LAVSplitter in the MPC-HC external filters list.

Hey quiet you! I was making him suffer a little. :p :D

[Snowknight26]

One of the most recent versions of the splitter has introduced a large delay when opening files (up to 5 seconds). I ran Process Monitor and saw that the splitter was reading the first 20MB or so of the file (in 4kB chunks!) before a graph was rendered (then started back from byte 0 after it was rendered). Switching to MPC-HC's internal (TS) splitter removed the delay.

The issue seems to be most prevalent with MPEG-TS files.
Process Monitor logs: http://stfcc.org/misc/mpchc_splitters.zip

[nevcairiel]

The underlying IO system should do read-buffering, therefor the read-size is irrelevant. And yes, on many files its actually required to read this much to find all the codec parameters. Stupid MPEG-TS doesn't define them properly.
If it takes 5s to read 20MB on your drive, you should get a faster drive.

Anyway, off to vacationing!

[Gleb Egorych]

"Lossy" codecs do not have a "proper" bitdepth, in a perfect world it would output floating point data as the ffmpeg decoder does.
Because the process is lossy, there won't be an "accurate" result, different decoders produce different results (most likely), and most decoders also decode to floating point .. ArcSoft is most likely just cutting/rounding to the bitdepth of the source material.
I understand that, bitdepth in DTS header is clearly source wavs bitdepth. Anyway generally you need to convert output bitdepth to integer, you can do in decoder or you may rely on windows mixer or ReClock. If it's done in a decoder and done properly it's OK for me. The only question is whether this is done properly in ArcSoft decoder :)

Unless you mean that its outputting 24-bit samples which only have 16bit filled? (Which i've seen before as well - but i may be able to influence that from the outside actually)
I don't know whether high-order bits are zero, I do know that 1.1.0.0 and 1.1.0.1 output different 24 bit streams and it looks suspicious in my opinion.

Regarding the "reference proper", over in the eac3to thread, some people compared output to the nero and sonic decoders, and apparently only the newer version of the ArcSoft decoder match the output of those two (which is otherwise identical) - on lossless DTS-HD MA only, of course, comparing bit-exactness of lossy is pointless.
AFAIK there is DTS-HD StreamPlayer which can be considered as a reference decoder. It's interesting how it decodes lossy and lossless tracks. Unfortunately I don't have it.

About eac3to: people in that thread discussed that MA 7.1 16/48 "strange setup" is not properly decoded with 1.1.0.0, and 1.1.0.8 is needed. Such track was found on "Black Hawk Down" blu-ray. I do have this blu-ray and I reproduced the problem, with 1.1.0.0 there is clearly audible noise. But it's eac3to problem, not ArcSoft! Noise appears only when decoding is done using eac3to, no noise when using 1.1.0.0 through LAV Audio. I dumped outputs of LAV Audio+1.1.0.0 and LAV Audio+1.1.0.8 and they were identical.

[madshi]

About eac3to: people in that thread discussed that MA 7.1 16/48 "strange setup" is not properly decoded with 1.1.0.0, and 1.1.0.8 is needed. Such track was found on "Black Hawk Down" blu-ray. I do have this blu-ray and I reproduced the problem, with 1.1.0.0 there is clearly audible noise. But it's eac3to problem, not ArcSoft! Noise appears only when decoding is done using eac3to, no noise when using 1.1.0.0 through LAV Audio. I dumped outputs of LAV Audio+1.1.0.0 and LAV Audio+1.1.0.8 and they were identical.
Can you upload a sample of the MA 7.1 strange setup track where that noise in audible with eac3to?

[Gleb Egorych]

madshi, sample sent. There is also a problem (http://forum.doom9.org/showthread.php?p=1502158#post1502158) with 6.1 decoding, bad decoding with 1.1.0.8, 1.1.0.0 is needed. Again, it's eac3to specific problem, LAV Audio is OK.

[dbone1026]

You can also double click LAVSplitter in the MPC-HC external filters list.

Ah yeah, that is how I was doing it previously

:thanks:

[madshi]

There is also a problem (http://forum.doom9.org/showthread.php?p=1502158#post1502158) with 6.1 decoding, bad decoding with 1.1.0.8, 1.1.0.0 is needed. Again, it's eac3to specific problem, LAV Audio is OK.
Sample? :)

[Gleb Egorych]

Sample? :)
Sample (http://www.mediafire.com/?jcie332d4231g8r). The problem appears with DTS-ES 6.1 and DTS-MA 6.1.

EDIT: sample link fixed, sorry.

[madshi]

Sample (http://forum.doom9.org/showthread.php?p=1502158#post1502158). The problem appears with DTS-ES 6.1 and DTS-MA 6.1.
There is no sample at that link.

[Snowknight26]

The underlying IO system should do read-buffering, therefor the read-size is irrelevant. And yes, on many files its actually required to read this much to find all the codec parameters. Stupid MPEG-TS doesn't define them properly.
If it takes 5s to read 20MB on your drive, you should get a faster drive.

The file was fully cached in RAM so no actual reading was done from the HDD.

I also found it peculiar that before the graph is rendered, the read-size is 4kB, but after, it's 64kB.

I'll try to get you a better analysis to show you that there is actaully a problem. :p

[CruNcher]

Snowknight26 i reported this some posts back very carefully and indepth and i found even more problems, though most of these stability/performance issues don't really show up in a Playback environment (major goal of lav splitter) but become very apparent when doing Dshow based transcoding with lav splitter (so blocking lav splitter outside of a Player environment is advised for the moment) as the source filter especially for .mpg and .ts so far ;)
And yeah MPCs Splitter doesn't suffer from this, funny though Cyberlinks splitter shares the same behaviour with lav splitter hehe ;)

http://forum.doom9.org/showpost.php?p=1502105&postcount=3261
http://forum.doom9.org/showpost.php?p=1502471&postcount=3309

[Gleb Egorych]

I added in my past post (http://forum.doom9.org/showthread.php?p=1508578#post1508578) information about 2.1 bug.

Also I ran eac3to with all 1.1.0.x versions of arcsoft decoder on lossy DTS files. As I understand eac3to patches streams to mark it 24 bit and to make all arcsoft versions output 24 bit. In this case outputs of all versions except 1.1.0.0 are identical.

So the final conclusion is following: the best version of dtsdecoderdll.dll is 1.1.0.1. It decodes all lossy streams to 24 bit, it doesn't have mono and 6.0 bugs, its decoding algorithm for lossy and lossless content wasn't changed in latter versions (except mono and 6.0 of course). The only problem of 1.1.0.1 (and all arcsoft versions) - silent LFE channel in 2.1 streams.

PS Version 1.1.0.1 came with the original release of TMT3, 3.0.1.120.

[Andy o]

thanks for the extensive testing!

[skingery]

I added in my past post (http://forum.doom9.org/showthread.php?p=1508578#post1508578) information about 2.1 bug.

Also I ran eac3to with all 1.1.0.x versions of arcsoft decoder on lossy DTS files. As I understand eac3to patches streams to mark it 24 bit and to make all arcsoft versions output 24 bit. In this case outputs of all versions except 1.1.0.0 are identical.

So the final conclusion is following: the best version of dtsdecoderdll.dll is 1.1.0.1. It decodes all lossy streams to 24 bit, it doesn't have mono and 6.0 bugs, its decoding algorithm for lossy and lossless content wasn't changed in latter versions (except mono and 6.0 of course). The only problem of 1.1.0.1 (and all arcsoft versions) - silent LFE channel in 2.1 streams.

PS Version 1.1.0.1 came with the original release of TMT3, 3.0.1.120.

I read yesterday that that Arcsoft will soon have a beta update to TMT5. Interesting to see if this changes this dll.

AndyVT has the details about the update over on Missing Remote http://www.missingremote.com/blog/arcsoft-totalmedia-theatre-5-update

[Thunderbolt8]

so for mono and 6.0 its still best to use 1.1.0.0 ?

[zipi]

Is there any reason why LAV Audio Decoder outputs 32 bit float on MP3s (or at all for that matter when connected to a real hardware audio renderer) ?

how can one disable floating point output ?

[CiNcH]

I am using 'ffdshow DXVA Video Decoder' to decode VC-1. It seems that for VC-1 within m2ts, VC-1 timestamp correction has to be enabled, and for VC-1 within MKV, it has to be disabled. Shouldn't this option only apply to m2ts?

[mindbomb]

does it have to be disabled for vc-1 in an mkv? that hasnt been my experience with other dxva filters.

[nevcairiel]

I am using 'ffdshow DXVA Video Decoder' to decode VC-1. It seems that for VC-1 within m2ts, VC-1 timestamp correction has to be enabled, and for VC-1 within MKV, it has to be disabled. Shouldn't this option only apply to m2ts?

VC-1 in MKV has terrible timestamps, and ffdshow DXVA can't deal with it properly, apparently.

[Andy o]

Is there any reason why LAV Audio Decoder outputs 32 bit float on MP3s (or at all for that matter when connected to a real hardware audio renderer) ?

how can one disable floating point output ?

I don't think you can, but what do you mean by "real hardware audio renderer"? Example?

[CiNcH]

VC-1 in MKV has terrible timestamps, and ffdshow DXVA can't deal with it properly, apparently.
It can. As long as 'VC-1 timestamp correction' is disabled. But then m2ts playback is choppy which requires the correction. If 'VC-1 timestamp correction' is enabled, m2ts playback is smooth, but MKV is choppy. Seems as if frames are being swapped in both "error" cases or something like that.

does it have to be disabled for vc-1 in an mkv?
Yes. At least when using 'ffdshow DXVA Video Decoder'. Maybe not with others. Maybe it also depends on the muxer. I sometimes use MakeMKV to place a Blu-Ray on my NAS.

Short summary:
m2ts -> LAV -> ffdshow DXVA Video Decoder: VC-1 timestamp correction has to be enabled, otherwise frames will be swapped
mkv -> LAV -> ffdshow DXVA Video Decoder: VC-1 timestamp correction has to be disabled, otherwise frames will be swapped

I thought that the correction is only necessary for m2ts, depending on the decoder that is being used (e.g. ffdshow vs. CyberLink).

[RealSnoopyDog]

I am using 'ffdshow DXVA Video Decoder' to decode VC-1. It seems that for VC-1 within m2ts, VC-1 timestamp correction has to be enabled, and for VC-1 within MKV, it has to be disabled.
Confirm, i have the same problem.

One of the most recent versions of the splitter has introduced a large delay when opening files (up to 5 seconds). I ran Process Monitor and saw that the splitter was reading the first 20MB or so of the file (in 4kB chunks!) before a graph was rendered (then started back from byte 0 after it was rendered).I also see this problem and i think, the read buffer is too small. I regulary run into problems when i watch movies from slower data sources, e.g. a "real" Blu-Ray in a BD-ROM. From one sudden to the next, LAV starts accessing the disc like hell and playback starts stuttering. This happens incidentially, it may happen, but must not. When i use a different splitter with the same Direct Show filters, the problem does not occur. Unfortunately, i don't have Visual Studio 2010 atm to compile the filter, only 2008. If i could compile it, i would play with BD_READ_BUFFER_SIZE a bit and see, what happens.

The underlying IO system should do read-buffering, therefor the read-size is irrelevant.After long year of expierience, i would not rely on this. :p

But thanks again for this software, it's getting better and better :)

[ryrynz]

I have a video which has some portions of the MP3 audio cut out on my Yamaha receiver when Auto AV Sync correction is enabled.
The audio is sent bitstreamed over HDMI, let me know if you'd like a sample.

[ney2x]

@nevcairiel

Just a quick question. Is there a plan for AC3 (SPDIF Encode mode) like the ffdshow? A friend of mine ask me...

Thanks.