LAV Filters - DirectShow Media Splitter and Decoders

[rica]

Q: Can LAV Audio decode DTS-HD?
A: Kind of. On its own, it cannot. But, LAV Audio supports using the ArcSoft DTS decoder, which allows decoding of full DTS-HD. Just drop the "dtsdecoderdll.dll" from the TMT3/5 Codecs directory into LAV Audio's directory, and enjoy. NOTE: This only works on 32-bit!


No it doesn't work for me. I carried dtsdecoderdll.dll into LAVFilters directory and unticked "DTS-HD" bitstreaming on LavAudio properties page. (so as to decode it to PCM)
Can you tell me what i am missing?

[SamuriHL]

No it doesn't work for me. I carried dtsdecoderdll.dll into LAVFilters directory and unticked "DTS-HD" bitstreaming on LavAudio properties page. (so as to decode it to PCM)
Can you tell me what i am missing?

I'm going to point out the obvious one that people overlook....you're doing this with the 32 bit version of LAV and NOT the 64 bit version.............right? :)

[roytam1]

I changed my mind, after i push all changes in a few hours, it should be working ok-ish for people that dare to test it.
You can follow progress here: http://code.google.com/p/lavfilters/issues/detail?id=139
Basics done, advanced features missing. ;)

OK. New nightly:
http://roy.orz.hm/lavf-w32-nightlies/lavf-my111124-mkv-rv34seekkeyframe-5b59265.7z

diff ( " " ):
http://roy.orz.hm/lavf-w32-nightlies/lavf-my111124-mkv-rv34seekkeyframe-5b59265.diff

[mindbomb]

i can confirm that it fixes all my previous problem files.

seeking is perfect now!

[golagoda]

OK. New nightly:
http://roy.orz.hm/lavf-w32-nightlies/lavf-my111124-mkv-rv34seekkeyframe-5b59265.7z

diff ( " " ):
http://roy.orz.hm/lavf-w32-nightlies/lavf-my111124-mkv-rv34seekkeyframe-5b59265.diff

Thanks for this, I was going to request for someone to post one so I could test it since I don't have visual studio to compile it :p

I'll test it out and see how it is, thanks nev and roytam.

[SamuriHL]

Thanks for this, I was going to request for someone to post one so I could test it since I don't have visual studio to compile it :p

I'll test it out and see how it is, thanks nev and roytam.

http://www.microsoft.com/visualstudio/en-us/products/2010-editions/express

You can TRY to compile it with that. Not sure if it'll work or not, but, you never know. :)

[Wodde]

Thanks to LAV Splitter and MC17 we already have BD Title Selection.

have i missed something?
I have LAV 0.40 installed, but there is no Titleselection?

EDIT: Ah, J.River 17.

Well thats fine, but thats a paid software, i prefer a free one ;)

What about MPC HC?

[roytam1]

http://www.microsoft.com/visualstudio/en-us/products/2010-editions/express

You can TRY to compile it with that. Not sure if it'll work or not, but, you never know. :)

Without some files from Pro Edition, you can't compile it. (I can't remeber well, it seems to be some afx* files)
And I'm waiting for alexins' new Cross-mingw package. (I'm still using Cross-mingw XvidVideo.ru 4.6.1 V.2)

[SamuriHL]

Without some files from Pro Edition, you can't compile it. (I can't remeber well, it seems to be some afx* files)
And I'm waiting for alexins' new Cross-mingw package. (I'm still using Cross-mingw XvidVideo.ru 4.6.1 V.2)

Ah well. It was worth a shot.

Sent from my Xoom using Tapatalk

[nevcairiel]

Good to hear that the new MKV demuxer seems to be working alright so far.
I'll implement some more missing features, and after that post an "official" test version, so that it can be tested over the weekend. I'm sure there will be some bugs to work out.

[BeNooL]

will this also fix playback of mkv generated by X264 where one cannot seek (using MeGui to encode) ?

When trying to seek, playback always goes back to start of video.

[nevcairiel]

Most likely, yes.
There will be a delay on the first seek while it builds a index, but further seeks should be working just fine and fast.

[sneaker_ger]

You mean we might have to wait for like 5 minutes, similar to ffmpegsource?

[madshi]

Most likely, yes.
There will be a delay on the first seek while it builds a index, but further seeks should be working just fine and fast.
Wouldn't it make sense to start building the index in a background thread right when the video file is loaded? Then, when the first seek isn't done right away, it might already work instantly?

[nevcairiel]

You mean we might have to wait for like 5 minutes, similar to ffmpegsource?

If the file is multiple gigabytes and does not have a seeking index in the file, it is quite possible that it will take a while - i'm unsure about 5 minutes though.

I have a 1.6GB file without such an index, and it takes about 10 seconds on a relatively slow harddrive to build that index. If the file is say a 1080p Blu-ray rip of 20GB, it would i guess take around 2 minutes or so (or even less on better hardware)

In general, you should rather remux those files to add an index instead. MKV sadly is not designed to seek without an index - so either you have one in the file, or you need to build one.
This is still a great advantage over the situation now, because now it doesn't allow seeking at all.

Wouldn't it make sense to start building the index in a background thread right when the video file is loaded? Then, when the first seek isn't done right away, it might already work instantly?

Building the index requires seeking through all clusters in the file (well, actually in 10MB steps, which could be increased to speed up index creation for the cost of more "inaccurate" seeks), which could have a serious impact on fluid playback.
It looks like Gabest MKV splitter always builds the index on opening, while Haali also builds it on demand (Hey, i'm using Haalis matroskaparser library afterall!)

Such files are just not perfect. If anything, they should only result as intermediate files in a encoding process, your final file should always have a Cue index, otherwise the mux is just wrong.

[mindbomb]

my experience has been that with my incomplete files muxed with haali's muxer, there is a slight delay.

However, the seeking problems with mature files muxed with mkvmerge have also gone away, and there is no delay at all in that case, despite they're large size.

[sneaker_ger]

I have a 1.6GB file without such an index, and it takes about 10 seconds on a relatively slow harddrive to build that index.

So that's why harddrives are so expensive today. I thought 160 MB/s was fast... ;)

Such files are just not perfect. If anything, they should only result as intermediate files in a encoding process, your final file should always have a Cue index, otherwise the mux is just wrong.

I agree, index is a must. I only use it for intermediate files/testing, so I can have a preview of the current x264 output, to decide whether I'm happy with the result or if I have to stop the encoding process.

[nevcairiel]

So that's why harddrives are so expensive today. I thought 160 MB/s was fast... ;)


It doesn't read every block of the file. It looks for a Cluster, reads its timecode, jumps 10MB further ahead, looks for the next cluster, rinse and repeat. I would guess it reads maybe 1/10th of the whole file, with alot of seeking involved.

ffmpegsource indexes the timestamp of every frame for frame-accurate seeking/editing, so it will be slower.
I would suggest to wait and test before drawing any more conclusions. :)

As an alternative to the index building i could implement a binary search seek, but that would mean seeking is never fast on such files, but there is no initial delay either. Not sure if thats better - but its surely alot of effort for files that are not really *that* common for normal users.

[Sebastiii]

have i missed something?
I have LAV 0.40 installed, but there is no Titleselection?

EDIT: Ah, J.River 17.

Well thats fine, but thats a paid software, i prefer a free one ;)

What about MPC HC?

You can try Mediaportal with BlurayHandler plugin (based on LAF Filter of course) :
http://www.team-mediaportal.com/extensions/movies-videos/bluray-handler-0-9-7
http://forum.team-mediaportal.com/mediaportal-plugins-47/bluray-handler-0-9-7-beta-81068/

Or Internal Bluray Menu on Mediaportal too :
http://forum.team-mediaportal.com/general-development-no-feature-request-here-48/native-blu-ray-support-102375/

Thanks :)

[Sebastiii]

Most likely, yes.
There will be a delay on the first seek while it builds a index, but further seeks should be working just fine and fast.

Yep, i can confirm that :)
Nice :)

[GRENDIZER]

Hello, I'm a new user of LAV and I have a question about bitstreaming.

My config: HTPC running Win7 64, soundcard; Realtek HD audio in motherboard, audio receiver and speakers: Logitech Z5500, cable: optical.

I've been checking if AC3 audio is working on these speakers, and it works. Testing the file "Test AC3 v2.0.avi", my audio receiver displays "Dolby Digital" and the surround test works.

One thing I do not understand is that in the LAV audio options, under "bitstreaming", wether "Dolby Digital (AC3)" is checked or not, the surround sound works, and the Audio receiver says it's "Dolby Digital". I thought that when it's not checked, LAV decodes the AC3 and in that case, the audio receiver would not receive any proper data?

Thanks
Gz

[masonwu]

haha nevcairiel ,thank you for your work effort on these filter . and could i use the binary filter in my HTPC product ? :readfaq:

[sneaker_ger]

You have to follow the GPLv2 (http://www.gnu.org/licenses/old-licenses/gpl-2.0.html), I guess.

[nevcairiel]

One thing I do not understand is that in the LAV audio options, under "bitstreaming", wether "Dolby Digital (AC3)" is checked or not, the surround sound works, and the Audio receiver says it's "Dolby Digital". I thought that when it's not checked, LAV decodes the AC3 and in that case, the audio receiver would not receive any proper data?


Some audio drivers have an option to compress any audio into AC3 when connected via Optical, so that you can send multi-channel PCM over the link, and are not limited to stereo.

In any case, as long as you get audio and it sounds good, all is well!

[Fullmetal Encoder]

...while Haali also builds it on demand (Hey, i'm using Haalis matroskaparser library afterall!)

Does this mean we are a step closer to having full MKV ordered chapters support? :p

[nevcairiel]

Baby steps. :p

[STaRGaZeR]

Isn't this the same parser as Haali uses for mkv? Seeking works surprisingly similiar (read: very good) :p

[nevcairiel]

Isn't this the same parser as Haali uses for mkv? Seeking works surprisingly similiar (read: very good) :p

Since its the parser he wrote, i would assume its also used by his DirectShow filter. :p

[STaRGaZeR]

Me likes :D

[rica]

I'm going to point out the obvious one that people overlook....you're doing this with the 32 bit version of LAV and NOT the 64 bit version.............right? :)

Yes, it is 32 bit version on Seven 32 SP1 and i'm trying to decode a dtshd-master audio.

[Mr.White]

I carried dtsdecoderdll.dll into LAVFilters directory

Did you put it in the \LAV Filters\x86 folder?

[rica]

Did you put it in the \LAV Filters\x86 folder?

I extracted 32 bit zipped version to C:\Lav Filters folder and there is no x86 sub-folder inside the Lav Filters folder? Are you using Seven 64?

[Thunderbolt8]

whats the difference of the normal compared to the .mkv branch? does it use haalis stuff for parsing?

[Mr.White]

I extracted 32 bit zipped version to C:\Lav Filters folder and there is no x86 sub-folder inside the Lav Filters folder? Are you using Seven 64?

Win7 32
I use the LAV installer, and there is an x86 folder inside the LAV Filters folder where i put the dtsdecoderdll.dll.

[Sebastiii]

For sure i put dll where is .ax :)

[robpdotcom]

Have you tried a different version of the dtsdecoderdll.dll? I had a similar problem once, and using version 1.1.0.8 fixed it.

[rica]

Have you tried a different version of the dtsdecoderdll.dll? I had a similar problem once, and using version 1.1.0.8 fixed it.

It is already 1.1.0.8.

[Sebastiii]

No it doesn't work for me. I carried dtsdecoderdll.dll into LAVFilters directory and unticked "DTS-HD" bitstreaming on LavAudio properties page. (so as to decode it to PCM)
Can you tell me what i am missing?

Did you uncheck dts too ?
:)

[rica]

Did you uncheck dts too ?
:)

Yes but i've explored LavSplitter doesn't recognize audio as DTS or DTS-HD in my case. Btw i'm trying to read from original BD. I'll keep you informed.

[nevcairiel]

Here is a "official" test build using the new MKV demuxer:

x86: http://files.1f0.de/lavf/LAVFilters-0.40-16-g19c9e9f.zip
x64: http://files.1f0.de/lavf/LAVFilters-0.40-16-g19c9e9f-x64.zip

What does "new MKV demuxer" mean for you, you ask?
Well, it does fix some issues, and improve other things. For one, playing of incomplete files should be working much better now (eg, Issues 42 and 103), and seeking should generally be faster (for MKV only, of course).

Ideally, there shouldn't be any regressions.
So if you feel like testing, grab the build above, and go test. If you find any MKV file that does no longer play properly, but did play fine before - please report that.

Otherwise, i hope it will be a smooth ride.
There is one known limitation though - you cannot have more then 64 tracks in a MKV. 64 is plenty though, and Haali already craps out at 32. ;)

[rica]

Yes but i've explored LavSplitter doesn't recognize audio as DTS or DTS-HD in my case. Btw i'm trying to read from original BD. I'll keep you informed.

OK guys, thanks a lot.

Unregistered all lav filters first and deleted all files under Lav Filters folder.
I copied dtsdecoderdll.dll first inside this empty LavFilters folder and unzipped 32 bit version and registered again all lav filters and fixed the issue :)

[sneaker_ger]

Just to be sure, the new mkv builds work totally independent from any installed Haali Media Splitter?

[nevcairiel]

Just to be sure, the new mkv builds work totally independent from any installed Haali Media Splitter?

Of course.
Its a plain old code library that Haali published quite a while ago which only does a low level parsing of the file. It has nothing to do with its DirectShow filter, except that it probably also uses it.

[sneaker_ger]

Of course.
Its a plain old code library that Haali published quite a while ago which only does a low level parsing of the file. It has nothing to do with its DirectShow filter, except that it probably also uses it.

Great. Only asking because ffmpegsource actually requires an installed HMS for certain file types.

[rica]

Gave it a go and sure 0.41 is ready to be published :)
Thanks nev for all your efforts.

[SamuriHL]

Yes, it is 32 bit version on Seven 32 SP1 and i'm trying to decode a dtshd-master audio.

Just thought i'd ask. :) It looks like you got it fixed now, so, all is well. :)

[rica]

Just thought i'd ask. :) It looks like you got it fixed now, so, all is well. :)

Yes, thanks but i think dtsdecoderdll.dll has to be already existent inside Lav Filters folder before registering Lav Audio.ax.
Dunno whether i'm right or not :)

[SamuriHL]

Yes, thanks but i think dtsdecoderdll.dll has to be already existent inside Lav Filters folder before registering Lav Audio.ax.
Dunno whether i'm right or not :)

That's not what I remember but if that's what works for you then it's all good. :)

[rica]

That's not what I remember but if that's what works for you then it's all good. :)

Yes you are right.
I tried again.
I re-unregistered all lav filters and deleted all the contents of Lav Filters folder and re-unzipped and re-registered all filters and copied dtsdecoderdll.dll later. Everything works again.
I must have made something wrong but anyway feedback is feedback? :)

[SamuriHL]

Absolutely. If you have an issue with getting it to work, feedback is definitely welcome. I'm just glad you got it working again. :) I have scripts that take care of this for me since I build my own LAV Filters and update my MC17 private copy. My script handles copying the dtsdecoderdll.dll file from TMT5 into my MC17 private copy of LAV. Works great.