View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
owlsroost
17th January 2013, 11:08
celsworth - update your MP installation to version 1.2.3 - there was a bug in older versions with handling weird aspect ratios (like 88672:49901) which was fixed in 1.2.3
Tony
celsworth
17th January 2013, 15:29
owlsroost, ok thanks, will give it a try :)
pururin
17th January 2013, 15:36
So apart from a/v sync handling, I think there is no real difference between LAV Filters and madFlac in playback various Flac files, correct?
What about this:
The only real reason to use madFlac I have heard has been about the splitter component, saying it exports more metadata from flac files.
tl;dr Not that I know (decoding-wise).
If splitter is the key, say if I use Haali media splitter then the outcome will be difference too? (especially for some multi-channel Flac files)
nevcairiel
17th January 2013, 15:54
JEEB was only talkin about metadata, which is optional information not relevant at all for decoding.
If you have a FLAC file that doesn't work as expected in LAV, let me know, otherwise i'm going to claim there are no differences.
madshi
17th January 2013, 15:55
I don't really know how LAV and madFlac compare. When LAV Audio Decoder first came out I tried it and had problems with the FLAC decoding. But that was *ages* ago. I guess the LAV FLAC decoder will probably work very well today. But I haven't really tried myself, so I can't say. And to be honest, I don't care much. madFlac has always worked perfectly fine for me, so I see no reason to stop using it. One thing to note is that libav/ffmpeg (which LAV uses for FLAC decoding) is constantly being worked on. When I recently updated the libav version eac3to ships with I had to do a lot of changes to make it compile. And they're working on totally changing the programming interface *again* right now. There's always a chance something could break once in a while (and then get fixed a few days later). madFlac is based on the official libFlac decoder which was last changed in the year 2007. So basically with madFlac there's no danger of anything breaking suddenly when you update to a new build. madFlac also hasn't been updated in years. Simply because there's no need to. That said, I understand the wish to reduce the number of filters you have to install. So try both and make up your own mind. Of course LAV has the advantage of supporting x64 media players, which madFlac does not support.
JEEB
17th January 2013, 16:02
If splitter is the key, say if I use Haali media splitter then the outcome will be difference too? (especially for some multi-channel Flac files)
What? Haali has no flac splitter as far as I know. Depending on how the FLAC stream is output I guess some kind of OGG wrapping might make it work with the OGM splitter Haali has, but I seriously doubt that.
Also what does metadata and multi-channel audio have to do with each other?
As nev said, decoding-wise there should be no difference, and if there is such, it should be reported instead of continuing a cargo cult.
madshi, excuse me (http://git.xiph.org/?p=flac.git;a=summary)? While certainly there have been no releases since 1.2.1, there are still commits being made to the flac repository, even if most of them most probably are regarding the build system and old hacks they had in there (I could note some code-wise changes as well though, looking at the changelog).
Also I do kind of see your hatred on libav* libraries as funny. And I would much more prefer dealing with an active project at which I know people that I can poke to dealing with a piece of software that is basically on eternal maintenance mode (and which I only lately found out had even that done to it). If there are bugs or features not yet in libavcodec, they should be squashed. That's all. It happened with wavpack and AAC in 2011, and it can happen with other formats as well.
Edit:
Just to note -- I do hate libavfilter's API and the code within libswscale, as well as I can see common dislike towards the sometimes quick changes in APIs in libav*. But it's still not a real reason to completely disapprove of it.
madshi
17th January 2013, 16:40
What? Haali has no flac splitter as far as I know.
Haali's MKV splitter supports FLAC audio.
madshi, excuse me (http://git.xiph.org/?p=flac.git;a=summary)? While certainly there have been no releases since 1.2.1, there are still commits being made to the flac repository
http://flac.sourceforge.net/changelog.html
Also I do kind of see your hatred on libav* libraries as funny.
[...]
But it's still not a real reason to completely disapprove of it.
Huh? What's wrong with you today?? Where did I say I completely disapprove or even hate libav? Please don't put words in my mouth. Especially not something which is the total opposite of the truth! :mad:
I absolutely very much like ffmpeg/libav. It's the very cornerstone of eac3to and I'm using it in madVR, too. What I don't like is that the interface is constantly changing and requiring me to do lots of changes to my own code all the time. But that is of no concern to users.
And I would much more prefer dealing with an active project at which I know people that I can poke to dealing with a piece of software that is basically on eternal maintenance mode
What's wrong with putting something which is "completed" (and working well without any bugs worth mentioning) on maintenance mode?
What I said is nothing but the truth: If you look through the LAV thread, there have been multiple occasions where updating to the latest ffmpeg/libav version resulted in new bugs which nevcairiel had then to analyze and fix himself. And this won't happen with a stable and "final" decoder implemention like the official libFlac used by madFlac. Now were there any bugs in FLAC decoding in LAV recently? I don't think so. Or is it likely that such bugs could crop up in the near future? Probably not. But the way libav works you always have to update all splitters and decoders, even the ones which were working perfectly in the previous version. So there always is a small risk new bugs could creep in into any of the supported decoders. That's just the way it is. And that's one reason I consider using the official libFlac decoder an advantage, because you don't have to update it just because something changed in e.g. the h264 decoder.
Now does that mean that I recommend that everybody should use madFlac? No, not at all. If you read my previous comment I mentioned advantages and disadvantages of both madFlac and LAV's FLAC decoder, and told pururin to make up his own mind. I don't know how I can be more objective than that.
Anyway, this is my last post on the topic of FLAC decoding in this thread.
JEEB
17th January 2013, 17:03
Haali's MKV splitter supports FLAC audio.
Yes, but I thought this was regarding FLAC without any extra wrapping in any containers.
http://flac.sourceforge.net/changelog.html
Yes, the change log only seems to contain releases, and since there have been no releases since, there is nothing on the change log.
Huh? What's wrong with you today?? Where did I say I completely disapprove or even hate libav? Please don't put words in my mouth. Especially not something which is the total opposite of the truth! :mad:
OK, do excuse me then. I just kind of read the feeling of "libav* is often API-unstable and thus automatically inferior." between the lines. There's just been too many cases of people dismissing libav* for various more or less random reasons and those feelings must've messed up with me :/
What's wrong with putting something which is "completed" (and working well without any bugs worth mentioning) on maintenance mode?
Absolutely nothing. And the fact that there are still commits on the flac git repository means that it's not yet completely abandoned, which is great by itself.
madshi
17th January 2013, 18:12
OK, do excuse me then. I just kind of read the feeling of "libav* is often API-unstable and thus automatically inferior." between the lines. There's just been too many cases of people dismissing libav* for various more or less random reasons and those feelings must've messed up with me :/
Ok, no problem. FWIW, I think libav/ffmpeg is by far the best and most important open source project for home cinema (without it LAV Filters wouldn't even exist). But that doesn't stop me from finding some things to criticize once in a while... ;)
P.J
17th January 2013, 23:52
How to set Dynamic Range to Full? :thanks:
Blight
18th January 2013, 01:13
nev, can you take a look at this:
http://www.d-cine.net/trailers/Promos/CandyBar/PopcornCombo_advertisement_DCP.zip
It uses the "MXF" format (http://www.pro-mpeg.org/pages/main.php?page=0002).
LAV is capable of decoding the audio file, which LAV Splitter is listing as "MEDIASUBTYPE_PCM {00000001-0000-0010-8000-00AA00389B71}"
The video file isn't fully supported, LAV Splitter lists the output pin as "MEDIASUBTYPE_mjp2 {32706A6D-0000-0010-8000-00AA00389B71}"
But LAV Video doesn't accept a connection from LAV Splitter on this file.
nevcairiel
18th January 2013, 11:37
MJP2 is JPEG2000, which is not supported by LAV Video, because ffmpeg has no native decoder for it.
madshi
18th January 2013, 11:48
http://www.openjpeg.org/ :D
nevcairiel
18th January 2013, 11:50
Yeah i'm not sure bundling this library is a good idea for a fringe format like J2K
madshi
18th January 2013, 12:18
Yeah, I'm not sure, either. MXF content is very rare.
Konrad Klar
18th January 2013, 14:51
Is there a chance for a settings specific to program?
I preffer best quality in general, but some programs do not accept audio with depth > 16 bit or with more than 2 channels, for example.
For such programs a special settings would be very useful.
mzso
18th January 2013, 15:27
What's wrong with putting something which is "completed" (and working well without any bugs worth mentioning) on maintenance mode?
I seem to remember (http://www.hydrogenaudio.org/forums/index.php?showtopic=84014) that it has serious limitations with file/stream sizes.
Blight
18th January 2013, 21:36
nev:
It's a shame, it seems this format is used by movie theaters to distribute content digitally.
Is there any MJPEG2000 directshow codec out there?
nevcairiel
18th January 2013, 21:39
If you happen to have such content, you should probably also have the software to play it. :p
I'm not going to bundle the openjpeg library, if avcodec ever gets native support (more then its rather broken experimental codec), LAV will automatically inherit it.
filler56789
19th January 2013, 01:20
Is there any MJPEG2000 directshow codec out there?
MainConcept MJ2 Video Decoder ( mc_dec_j2k_ds.ax + mc_dec_j2k.dll ).
wanezhiling
19th January 2013, 05:07
MPC-BEs video decoder seems to support. http://i6.minus.com/jbrw1fbViqpyV7.png
nevcairiel
19th January 2013, 08:20
Probably enabled the experimental decoder in avcodec, but its rather unstable and crashes a lot, or the bundled the openjpeg library, but neither are options i'm willing to do for a format which is of no importance.
Pomegranate
19th January 2013, 09:14
Would it be possible to have a mediainfo tab (or anything similar) inside LAV Splitter menu during playback?
GrandeBoma
19th January 2013, 10:49
I am experiencing problems with dtsdecoderdll.dll placement in windows 8 64 bit and jriver 17. I have tried to put it in lav folders and in sys64WOW folders, without any result. Contrariwise, when i use windows xp 32 bit in another partition I can easily copy the same file in lav or system32 folders and in this case it is properly decoding dts hd ma to pcm. Is there a different folder where I have to place the file in win8 x64? Is there a different version of dtsdecoderdll.dll to be used in this case?
P.S. obviously i am referring to red october HQ which shows LAC audio decoder in use in both cases
jmone
19th January 2013, 11:21
You can tell it is working by just clicking on the Audio Path button in Std View - as per second pic in the wiki http://wiki.jriver.com/index.php/Audio_Path . If it just says DTS it is not using the dtsdecoderdll.dll.
GrandeBoma
19th January 2013, 11:50
I have already checked, it is confirmed it only works in winxp x32 but not in win8 x64
i installed it in the folders recommended for win7 x64 but it is not working
Vasilich
19th January 2013, 12:16
Frequently asked Question (http://forum.doom9.org/showthread.php?p=1425964#post1425964)
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!
jmone
19th January 2013, 12:29
FYI - JRiver Media Center is a 32-Bit app so it works fine (including on a Win7-64Bit OS), the issue seems to be on Win8-64 Bits OS. I don't have an Win8 Box to test but I'm sure others do.
pururin
19th January 2013, 12:34
Frequently asked Question (http://forum.doom9.org/showthread.php?p=1425964#post1425964)
I think that means 32 bit apps not the OS as I'm using it in win7 64 bit.
- - - - - - - -
Also I would like to THANK Nev, madshi, JEEB and others for your support and clarification. Really appreciate. :)
apgood
19th January 2013, 12:47
By lab folders do you mean the local that jriver has installed lab audio to? If not then it might be worthwhile copying there or installing your own version of lab and using the custom settings feature in jriver for audio.
Though I do have some vague recollection of reading somewhere that win 8 has tighter controls around use of ell files so that might be the issue.
Sent from my HTC One X using Tapatalk 2
GrandeBoma
19th January 2013, 15:37
i mean precisely lav folders installed by jriver, it does not work in those
nevcairiel
19th January 2013, 15:48
Depending on the version of the DLL you have, you need the 2003 or 2005 C++ runtime. The 2005 version you can get directly from Microsoft here: http://www.microsoft.com/en-us/download/details.aspx?id=3387
Only the very old versions of the ArcSoft DLL need the 2003 variant (1.1.0.0 and 1.1.0.1 i think), but sadly that one is not easily available on the net.
khagaroth
19th January 2013, 17:43
Note that FLAC is now maintained by Xiph for some time already. The repository and development moved to Xiphs git (https://git.xiph.org/?p=flac.git;a=summary).
JEEB
19th January 2013, 18:07
Note that FLAC is now maintained by Xiph for some time already. The repository and development moved to Xiphs git (https://git.xiph.org/?p=flac.git;a=summary).
Yes, I happened to link that during the discussion :)
GrandeBoma
19th January 2013, 19:09
is the c++ not included in win8 pro?
nevcairiel
19th January 2013, 19:34
is the c++ not included in win8 pro?
No. They don't bundle those. Applications that need it are supposed to bring their own.
P.J
19th January 2013, 20:09
No support, no thanks.
filler56789
19th January 2013, 20:32
Just for the notes, the Arcsoft DTS DLL depends on msvcr80.dll and msvcp80.dll ( according to my hex editor at least :) ). Also, the ancient VS 2003 runtimes are part of the .NET environment (or at least I think so):
mfc70.dll
mfc71.dll
mfc71u.dll
msvcp70.dll
msvcp71.dll
msvcr70.dll
msvcr71.dll
ERROR: too many DLLs :D
nevcairiel
19th January 2013, 20:33
Only msvcr71.dll and msvcp71.dll are required for the old ArcSoft decoder, the others not (and yes, they are part of the .NET 1.1 runtime). And the newer versions indeed use msvcr/p80.dll, which is the 2005 runtime.
mark0077
19th January 2013, 20:44
Do you guys keep the c++ runtimes up to date. I see some sites with all c++ runtimes in one installer. Updated very frequently. I assume that means they should be kept updated and windows update doesn't do that?
nevcairiel
19th January 2013, 20:47
Windows Update does update them if you install them with the official installer.
SamuriHL
19th January 2013, 22:01
I have the VC++ runtime installed and I can't get the dtsdecoder dll to work on W8 pro, either.
GrandeBoma
19th January 2013, 22:37
so perhaps it is a problem that should be looked into, how to make it work under win8
MarkT
19th January 2013, 22:39
If unsure what .DLLs are required, use http://www.dependencywalker.com/ (Freeware) to figure it out.
SamuriHL
19th January 2013, 22:40
It works under TMT. Just not under LAV. Which blows cause with my new TV I can actually use Video Clock to keep things stable but without proper DTS-HD MA decoding, not so much.
nevcairiel
19th January 2013, 22:46
You can test if 0.55.0 worked, it did the loading of the dll a bit differently (only that version, not earlier or newer).
Otherwise, early adopters always get burned. :p
SamuriHL
19th January 2013, 22:48
LMAO. :) I'll give it a try later. If I can find it.
nevcairiel
19th January 2013, 22:51
I know why i am laughing, because i have a Windows 7 HTPC in perfect working order, why you're laughing, i don't know. :p
All old releases (up to a point) are on Google code:
http://code.google.com/p/lavfilters/downloads/list
PS:
The best chance of the DLL being loaded would be when you put it into the system directory (%WINDIR%\SysWoW64 for a 64-bit OS)
SamuriHL
19th January 2013, 22:53
The early adopter comment. If I can't get decoding working it's not the end of the world. Just means I can stabilize my video with Video Clock.
jmone
20th January 2013, 02:02
Well....I may agree on a multi purpose PC but 100% I'd roll back to Win7 if I could not get it to work on a dedicated HTPC (pretty big limitation IMO and few other advantages for Win8)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.