LAV Filters - DirectShow Media Splitter and Decoders

[MasterNobody]

oh. forgot to mention. XP SP3. And all this in MPC-HC

[STaRGaZeR]

The new defaults will be more sane regarding subtitles enabling. I understand how people got confused by some of the behaviour right now.

After thinking around a bit, I think I got it backwards. I don't think Haali disables subs when there is no forced or default flag, I think that it doesn't enable them if they are missing. This is how I think Haali's stream selection is:


stream = none;

if (user_settings) {
stream = findtrack(); // All logic goes here. Sky is the limit.
} else if (forced_flags) {
stream = findfirstforcedtrack();
} else if (default_flag) {
stream = finddefaulttrack();
}

return stream;

What do you think about it?

[nevcairiel]

I really havent used Haali much, but i guess what you're saying is that once you configure a language in haali, you will always get subs, no matter what (unless you use that advanced config with a "off" setting)? The only difference to LAV Splitter being the behaviour without configuration, i guess.

[pankov]

Nev, guys,
now that you are on the subtitles subject can someone help me with the following problem (general as I see it):
Is there any way to have internal and external subtitles working together? By "working together" I mean that the "cycle" function (next/prev subtitle track) should be able to go through both internal (via the stream switching interface exposed by the splitter) and external subtitle files (via the stream switching interface exposed by subtitle renderer - either VobSub/FFDShow or MPC's internal one).
Is there a way that the media player can distinguish between the different tracks (audio/video/subs) exposed by the splitter and somehow combine only the subtitles ones with the ones from the subs renderer?

This is something that a lot of non English speaking people who use external subs in their language need when they try to learn the foreign language.

[nevcairiel]

The external subtitles are not managed by the splitter, and the way external subs are managed is different in every player out there, so its really a player task, imho.

I know that someone wanted to try combining those two in the MPC-HC subtitle selector, because right now you have to switch in two different menus..
There is a kind-of standard how streams are grouped in IAMStreamSelect, so it should be possible to do it.

[STaRGaZeR]

I really havent used Haali much, but i guess what you're saying is that once you configure a language in haali, you will always get subs, no matter what (unless you use that advanced config with a "off" setting)? The only difference to LAV Splitter being the behaviour without configuration, i guess.

Not sure, as I don't use any of those features. However that goes into the user_settings if, and each splitter has its own options and stuff. As you say, the point I'm trying to make is that its default config is optimal IMHO. Can you find any flaws or corner cases in it?

[nevcairiel]

As you say, the point I'm trying to make is that its default config is optimal IMHO. Can you find any flaws or corner cases in it?

Its a matter of taste, imho. Personally, i usually don't want subs. Forced subs are OK, but normal subs i rather never see, so selecting the default track is not perfect for me.

But then, a default setting will never be perfect, its really a matter of choice.

I can certainly configure it like that. When no languages are configured (and settings not touched in general), use forced/default, but nothing else.
I would tie that to the audio settings, though, so when the user configures audio languages, but no subtitle languages, then at least it trys to select a forced track that matches the audio language - if one is present. If no match is found, fallback to the old logic and try any forced track, and then the default track.

I really don't have much MKVs with subtitles. How is the default flag really used? Do people typically keep it on the one stream that mkvmerge put it on, just because? Or does it have a meaningful use?

[mandarinka]

It *should* use the MMX version on any Athlon that has SSE2, but does not have SSE4a. Apparently the ffmpeg developers came up with that scheme to detect if a Athlon has slow SSE2.

This nitpick is probably going to be almost irrelevant, but for the sake of completeness...

I suspect that noone has tested this heuristic for the lowend/low-power AMD chips (Bobcat core, a.k.a. Ontario/Zacate/E-350/C-50 etc).
Those cpus reportedly have support for SSE1-3,SSSE3 and SSE4a (and no 3dNow), According to some unofficial info, the SSE instructions get split into two microops just like how it was on A64. OTOH that doesn't necessarily mean it also has to have SSE2 slower than MMX like K8, though.

[glorp]

I really don't have much MKVs with subtitles. How is the default flag really used? Do people typically keep it on the one stream that mkvmerge put it on, just because? Or does it have a meaningful use?

I don't think Haali really respects it at all (possibly depending on which set of Haali options are used). The advanced option doesn't seem to care anything about the forced flag since it doesn't have any kind of syntax for dealing with it nor have I ever noticed it overriding my old configuration. That's what caused me some initial grief with LAVFSplitter's sub handling because I couldn't simply switch over to relying on the 'Select Only Forced' subs option. The ones I wanted weren't always marked forced. And I imagine this will often be the case in 'third party' muxes.

I do use forced now however as you set up the option and I think it would be valubale to at least respect it for cases like "english for non-english parts" sub tracks. I went thru and changed all the desired tracks to 'forced' in my muxes (thanks to whoever suggested using mkvmerge header editor for that) so that I could still get the same on/off sub behavior.

[STaRGaZeR]

But then, a default setting will never be perfect, its really a matter of choice.

Indeed. But I would do it like Haali for these two reasons: because I do think it is the best default approach when there are no user settings; and because it's already on Haali, the "reference" MKV splitter, so most people expect Haali behavior.


I can certainly configure it like that. When no languages are configured (and settings not touched in general), use forced/default, but nothing else.
I would tie that to the audio settings, though, so when the user configures audio languages, but no subtitle languages, then at least it trys to select a forced track that matches the audio language - if one is present. If no match is found, fallback to the old logic and try any forced track, and then the default track.

That sounds nice.

I really don't have much MKVs with subtitles. How is the default flag really used? Do people typically keep it on the one stream that mkvmerge put it on, just because? Or does it have a meaningful use?

Typically mkvmerge does everything because muxers either don't know about the option or they don't care, which means default flag in the first track. I've only seen two cases where users explicitly set them manually:

- When you want subs in your MKV but disabled by default, like in all other containers without flags. To do this, you set all of them as no in mkvmerge. Since there are no flags, Haali doesn't display any subs as intended.
- When you have several subs in your MKV, and you want to display a track by default that isn't the first one.

Both cases assume Haali default behavior: no subs unless the flag is set.

[stinman]

Is this what this is for? is this the same decoder that LoRD MulDer uses in his simple x264 launcher? I've seen and heard of this but not familiar with it. At the moment I use mpc-hc x64 and ffdshow x64 3785 clsid and want to know if there is any benefit to using this in place of mpc-hc own splitter.I can bitstream the DTSHD-MA audio to receiver with ffdshow.Thanks.

[4h4h270]

I find .34&.35 lav video decode h264 10bit variable frame rate will drop frames sometimes.
But I use .33&ffdshow they work perfect.

[nevcairiel]

There is really no difference between 0.33 and 0.34 except that it has much faster converters, so i consider that unlikely to be the case.

[Xaurus]

nevcairiel,

Not sure if it's very interesting but I ran a few tests with the 42 mbit/s Birds clip on my system (5 runs per decoder). http://www.megaupload.com/?d=1D4BX1U9
All output set as YV12.

LAV Video 0.35:
Avg: 187,6698 fps

ffdshow Video rev. 3972:
Avg: 184,0087 fps

CoreAVC 3.0:
Cuda avg: 47,3796 fps

LAV CUVID 0.12:
Avg: 47,2249 fps

CoreAVC 3.0:
No acc. avg: 40,4673 fps

CPU: Intel Core i7 980x @ 4015 MHz (6 threads, HT off)
GPU: Nvidia 570 GTX
After thinking about these numbers for a while, aren't the CUDA based numbers a bit low? About ~47 fps with both CoreAVC and LAV CUVID.

Compare this to 1 thread CPU (~40 fps) or 6 threads (~187 fps)...

I don't get it, I would like to think that using the GPU should be _much_ _much_ faster.

[nevcairiel]

After thinking about these numbers for a while, aren't the CUDA based numbers a bit low? About ~47 fps with both CoreAVC and LAV CUVID.

Compare this to 1 thread CPU (~40 fps) or 6 threads (~187 fps)...

I don't get it, I would like to think that using the GPU should be _much_ _much_ faster.

The GPU decoders are actually quite alot slower then any good software decoder running on a modern CPU.

On "normal" 1080p content (Blu-ray type files), the GPU (speaking about a VP4) does usually 70 fps, but with some special files like that high-bitrate file, the speed can go down.
Although i thought i did run that file before, and achieved over 60 fps. Which OS and drivers are you on? With recent drivers on Win7, it should be higher then 47 fps, on XP it might actually be like this.

The GPU decoder is basically a small dedicated piece of silicon. Its designed to run fast enough for 1080p60 (achieveing around 70 fps). It does not actually use the main 3D engine of the GPU - therefor it also does not matter how fast your GPU is, as long as it reaches the minimum speed to sustain the decoder.

[Xaurus]

The GPU decoders are actually quite alot slower then any good software decoder running on a modern CPU.

Which OS and drivers are you on? With recent drivers on Win7, it should be higher then 47 fps, on XP it might actually be like this.
Okay, interesting stuff.

So really the only benefit of LAV CUVID is the hardware deinterlacing if I understand you right?

Driver version: 280.36
OS: Windows 7 Pro x64

[CruNcher]

Not only the independence of DXVA limitations can be very beneficial for hardcore bitstreams that would play with Nvidias API but not with DXVA correct, the same for Intel and AMDs Native ways all of them are more error prone but all of them suffer from physical overhead which Nvidia so far got very good under controll (Performance wise) even being discrete :)

The GPU decoders are actually quite alot slower then any good software decoder running on a modern CPU.

On "normal" 1080p content (Blu-ray type files), the GPU (speaking about a VP4) does usually 70 fps, but with some special files like that high-bitrate file, the speed can go down.
Although i thought i did run that file before, and achieved over 60 fps. Which OS and drivers are you on? With recent drivers on Win7, it should be higher then 47 fps, on XP it might actually be like this.

The GPU decoder is basically a small dedicated piece of silicon. Its designed to run fast enough for 1080p60 (achieveing around 70 fps). It does not actually use the main 3D engine of the GPU - therefor it also does not matter how fast your GPU is, as long as it reaches the minimum speed to sustain the decoder.

Im not 100% sure but i think Nvidia uses CUDA to fix a problem with certain Mpeg-2 Bitstreams in all VPs up to 4 (5 seems not be affected), neuron2 had to code a special cuda decoder for this problem and it seems Nvidia put the same solution since some time now directly into the driver ;)

[nevcairiel]

Im not 100% sure but i think Nvidia uses CUDA to fix a problem with certain Mpeg-2 Bitstreams in all VPs up to 4 (5 seems not be affected), neuron2 had to code a special cuda decoder for this problem and it seems Nvidia put the same solution since some time now directly into the driver ;)

Thats true, for MPEG-2 there is actually a decoder written in pure CUDA, but all other formats seem to fallback to the default cuvid decoder when you ask for a CUDA decoder.
But MPEG-2 is unimportant.

[CruNcher]

Yep absolutely true even Intels Decoder roughly saves 1W here compared to libavcodec in DXVA mode for High Bitrate Mpeg-2
But still depending on the CPU that can be more or less and SB is very Energy efficient not to forget :)

[Eliminateur]

i wonder if the new Celeron G520 (2.5GHz, dual-core, sandy-bridge uarch) has enough "oomph" to decode 1080p with FLAC audio in software, either with LAV decoder of ffdshow....
anyone with day-zero hardware to test it?.
i know my Xeon 3075 (dual-core, 2.66Ghz, Conroe C2D 65nm -same arch as the original C2D but more FSB-) is not enough(not with HQ RGB32 conversion) and even with YUV output it's barely enough with ~90% usage, so i'm wondering if a uarch roughly 4~5 generations newer but with 2.5GHz would be enough.

anyone with a Pentium G620 to test it? (1MB more cache and 100MHz more clock)

[nevcairiel]

Yep absolutely true even Intels Decoder roughly saves 1W here compared to libavcodec in DXVA mode for High Bitrate Mpeg-2
But still depending on the CPU that can be more or less and SB is very Energy efficient not to forget :)

Me personally, i would rather use software decoding on a decent CPU, and find a way to use hardware deinterlacing with a software decoder without EVR ... it should be possible, afterall, thats what DXVA2 VP/DXVA-HD is all about.
The question is if its fast enough, with NVIDIA i bet it is, for the others, i cannot say. :)

[jmonier]

But MPEG-2 is unimportant.

Why? HDTV in the US is all MPEG-2.

[nevcairiel]

Why? HDTV in the US is all MPEG-2.

All i meant is that a 10 year old PC can probably decode 1080p MPEG-2, its such a simple format that the processing of it is not relevant in any performance considerations.

But MPEG-2 is also obsolete, you can get higher quality in less bytes with H264. Too bad the stations don't notice that. :p

[CruNcher]

@nev
HTPC as hard as it sounds are obsolete anyways HTARMs are replacing them slowly i cant wait to see how people will be amazed by tegra 3 based solutions Omap 4 based ones (this year) already have a wow effect but Tegra 3 yum yum ;)
Intel needs to hurry with Tri-Gate and 22nm ;)

[nevcairiel]

Those are still too slow. The CPUs in them are too slow for anything good, they only work for media playback because they again have a GPU with decoding capabilities, still leaving us with the problem of hardware decoders, and their limits.

I'm sure we'll always have better, more flexible, more compatible, software codecs then any hardware implementation. Hardware decoder for H264 10bit, or 4:4:4? I don't see it happening in the next 2 years or so, if even then.
As i said before, CPUs get not only faster, but also alot more efficient. Gaining in efficiency and speed is a win-win for us. So why use a limited hardware decoder chip, if my CPU is sitting there idling away anyhow? I don't really care for that extra few watts of power it uses. If i wanted a "simple" solution, i would certainly use a pre-built device with a power usage way below any HTPC.

[CruNcher]

yeah since Atom research found its way into Intel Desktop systems it changed massively idling @ 6W-8W is impressive (without the whole system overhead mainboard,ect pure CPU) :)
And Tri-Gate is another revolution to come vs ARM, i wonder if people rather imagine how much more powerfull this research intel does means for x86 (we already see Quantum mechanics effects here) then what AMD achieved with APUs, especially as intel was first here too ;)

[Xaurus]

Me personally, i would rather use software decoding on a decent CPU, and find a way to use hardware deinterlacing with a software decoder without EVR ... it should be possible, afterall, thats what DXVA2 VP/DXVA-HD is all about.
The question is if its fast enough, with NVIDIA i bet it is, for the others, i cannot say. :)
Would it not be possible to add the hardware deinterlacing capabilities of LAV CUVID to LAV Video somehow?

Then people with strong CPUs and some sort of Nvidia GPU could simply use LAV Video for everything.

With that said, it's not often that I need to use a deinterlacer.

[nevcairiel]

Would it not be possible to add the hardware deinterlacing capabilities of LAV CUVID to LAV Video somehow?

The NVIDIA raw YUV extensions aren't really implemented, as far as i know.
It would however be possible to do this through DXVA2 Video Processors - with the usual downsides of copying the decoded video to the GPU, and then back again. Not a big deal for NVIDIA, but for ATI thats a damn slow process.



With that said, it's not often that I need to use a deinterlacer.
Neither do i, but i don't want to worry when i find one. :)

[jmonier]

All i meant is that a 10 year old PC can probably decode 1080p MPEG-2, its such a simple format that the processing of it is not relevant in any performance considerations.

I understand your point now and I agree.

But MPEG-2 is also obsolete, you can get higher quality in less bytes with H264. Too bad the stations don't notice that. :p

I would very much like to see h264 for US TV but the problem is not with the stations but with the consumer equipment in the US: 1) There is too much equipment still around that was manufactured prior to the addition of h264 to the ATSC standard in 2008. 2) Apparently h264 is not being incorporated into more recent equipment (I guess it's not a mandatory part of the standard).

This is one area (at least) in which you in Europe are way ahead of the US but it leaves me with a major requirement for MPEG2 for all my TV recordings (not to mention the DVD's which are not available in Bluray).

[SamuriHL]

Both my Tivo Premiere XL and my motorola cable box running Tivo (from the cable company) support h.264. I really truly wish they'd start using it as it'd allow them to offer higher res in less bandwidth and potentially offer more HD channels without taxing their networks. Add DD+ into that and we're good to go. :D But, you're right, the US is not even close to caught up on this front. Still LAV Video and LAV CUVID handle my tivo recordings just fine so I can't complain.

[cyberbeing]

I build you a MMX P010 thingy.

http://files.1f0.de/lavf/LAVFilters-0.35-P010-mmx.zip

Unfortunately, the MMX version is considerably slower than the SSE2 version. Yet since only the rare piece of SSE2 code runs slow on A64, this isn't particularly surprising. Too bad it wasn't that easy, but that's why we test things...

SSE2 P010 = ~64fps
MMX P010 = ~59fps

What about a 3DNOW version? 3DNOW should be faster than MMX on A64.
I'm now thinking this may not be worth the effort, so if you think you can make the SSE2 version faster, you may as well just do that...

[nevcairiel]

What about a 3DNOW version? 3DNOW should be faster than MMX on A64.

3DNow is really only for floating-point calculations. It only has a very limited set of integer functions (nothing of use here). Its also only running on 64-bit operands like MMX (SSE2 is 128-bit).

Well the MMX was worth a shot, i could probably try some different things if i actually had the hardware up and running, but now its not really worth the effort i think. I did actually optimize the SSE2 code slightly last night as well, which should give a small boost as well.

[fastplayer]

Probably not worth the effort as darkshikari himself rates K8's SSE2 unit as "sh*tslow" (http://www.cccp-project.net/forums/index.php?topic=3249.msg22981#msg22981). :D

[nevcairiel]

Well his SSE2 code is vastly more complex. Mine is just something like: For Y, Load, Shift, Write. And for U/V: Load, Shift, Interleave, Write. Its really only 4 instructions, instructions that should be trivial. :)

Now if he complained that the RGB32 converter is slow on his Athlon, that would be a different deal, thats a more demanding code. :p

[cyberbeing]

Phenom 2:
AMD fails. They didn't send me a prerelease chip to bench on and optimize for!

Way off-topic, but the above made me lol from the thread fastplayer linked. How much things change in two years.

< Dark_Shikari> So, more good news.
< Dark_Shikari> I just got the go-ahead to meet with AMD guys in-person at their actual HQ.
< Dark_Shikari> Let me just say in simple terms:
< Dark_Shikari> AMD can get more done in 30 minutes than Intel can get done in 2 years.
< Dark_Shikari> Me: "I want a bulldozer." AMD: "Give us an address."

[nevcairiel]

Thats all AMD can do, they are miles behind Intel, so they have to do something. :)

[STaRGaZeR]

Wait for AVX2 and you'll see some serious shit :D

[SEt]

You say GPU<->CPU data transfer is fast on nVidia. How? CUDA only? Just locking DXVA2 NV12 1080p surface for readout gives me spikes up to 60ms on G92 card.

[cyberbeing]

Wait for AVX2 and you'll see some serious shit :D
Haswell should be amazing, but first we need to wait for SandyBridge-E, IvyBridge, IvyBridge-E, until it hopefully arrives in 2013. With IvyBridge getting pushed back, Haswell w/ AVX2 could even fall into 2014 if AMD doesn't bring some solid competition...

[BloodySword]

The x86 system is at it's limit. There will be no much performance gain I think...
Fact is, that x86 will die with Windows 8.

[nevcairiel]

The x86 system is at it's limit. There will be no much performance gain I think...
Fact is, that x86 will die with Windows 8.

Nonsense. There is no architecture to replace it (yet).
ARM? Efficient CPUs, sure. But they lack in high-end speed. They are good for embedded systems, phones, tablets, even small laptops, but if you want Desktop like performance, you need more.
Its also lacking the whole support architecture. x86 thrives on the easy mix-and-match of components. ARM is basically for SoCs right now. I, as a user, like being able to pick one CPU, pick a GPU, pick every component, and assemble a system.

ARM is not there yet, it'll be quite a couple of years until then.

Intel is doing the right thing, they are developing actual improvements, instead of just trying to push performance. The Tri-Gate transistors are a good thing, and they'll allow x86 to get stronger in some areas where its lacking right now.

[mindbomb]

is there any chance you will create some type of wrapper for wmvideo decoder dmo like ffdshow did?

the reason i ask is because i think it would be neat to be able to use the output from that decoder with things like the rgb conversion and the planned yadif deinterlacer in lav video.

also, i heard you are working with eric gur for quicksync support, is that true or just errant speculation?

[mandarinka]

The x86 system is at it's limit. There will be no much performance gain I think...
Fact is, that x86 will die with Windows 8.

x86 are close to fastest cpus in existence (if not fastest, only very heavyweight and expensive big iron can beat them), they are sold for prices everybody can afford as long as they have some basic income, the software for them is ubiquitous and there is a broad selection of accompanying hardware on sale for the best price. Intel has significantly increased the performance of a single core MHz-for-MHz three times in last years (2006,2008,2011; AMD did this in 2007) and that's while keeping compatibility with all the good old & new software.
So what exactly do you think is bad about x86? That's it's actually pretty good? Other architectures can find a niche via some special feature, but can't challenge x86 as the general-purpose cpu as it stands.

[SamuriHL]

Nuh uh. X64 rules. /sarcasm. :D

[Monamona]

Does LAV Video Filter support DXVA?
It seems not.

[Midzuki]

Fact is, that x86 will die with Windows 8.

Funny, that's not much different from:

Originally Posted by lachs0r (http://doom10.org/index.php?topic=1269.msg8891#msg8891)

First of all, use an operating system from this decade. I will not support Windows XP and older. This **** needs to die.

I see — "they" ;) have hired you both, alright :D

[STaRGaZeR]

Haswell should be amazing, but first we need to wait for SandyBridge-E, IvyBridge, IvyBridge-E, until it hopefully arrives in 2013. With IvyBridge getting pushed back, Haswell w/ AVX2 could even fall into 2014 if AMD doesn't bring some solid competition...

I expect them between late Q2-early Q4 2013, considering the rumored IB launch date. Let's hope BD doesn't suck as much as everything since the A64.

[dead_screem]

Here are some bugs I found
First there are two splitters "LAV Splitter" and "LAV Splitter Source". "LAV Splitter" seems to be the only one of the two that dshow will ever use, and even though it's merit is 0x00800004 it still loses out to Haali even though Haali has a merit of 0x00800001. This is because "LAV Splitter" relys on the "File Source (Async.)" filter which has a merit of 0x00400000. And since Haali is higher than "File Source (Async.)" Haali wins out.
Now, "LAV Splitter Source" doesn't need the "File Source (Async.)" because it doubles as one apparently, and it also has a merit of 0x00800004 which is higher than Haali but Haali still gets used for some reason, infact even when lowering Haali's merit way down "LAV Splitter Source" still doesn't get used, there is probably a bug which is preventing dshow from finding it. The only way I can get dshow to use it is by forcing it's use by setting "Source Filter"="{B98D13E7-55DB-4385-A33D-09FD1BA26338}" at HKEY_CLASSES_ROOT\Media Type\Extensions\.ts for example.

Also, the "LAV Splitter" and "LAV Splitter Source" have the same merit, which isn't good imo. I reccommend setting "LAV Splitter" to 0x00400000 merit as it is not the one that should be used. "LAV Splitter Source" is the one that shoud be used, that is if you can figure out what's wrong causing it to never get used.

When LAV Video filter is installed, if you use Microsoft's Graphedit and go to Graph->Insert Filter... then try to expand Direct Show Filters, Graphedit will suddenly exit (it doesn't appear to crash).

Another bug is the LAV Splitter TS splitter can't seem to connect AAC streams to MPC-HC/gabest or CoreAAC. However LAV Splitter mp4 aac and mkv aac seem to connect fine to MPC-HC or CoreAAC...

Also a few feature requests, can we get a tray icon for the splitter? it really makes switching streams easier if you don't have to go through the player.
And what about supporting service/menu switching in TS files? Haali is the only one to support this IIRC. What I mean is, to switch to a secondary set of associated video/audio PIDs such as 1seg in japanese ISDB-T streams.

[CruNcher]

Hehe not bad 0 out of 0 nothing of what you list there is actually a bug by Lav Splitter ;)

[nevcairiel]

also, i heard you are working with eric gur for quicksync support, is that true or just errant speculation?

Just speculation. I'm not sure its really worth it.


Now, "LAV Splitter Source" doesn't need the "File Source (Async.)" because it doubles as one apparently, and it also has a merit of 0x00800004 which is higher than Haali but Haali still gets used for some reason, infact even when lowering Haali's merit way down "LAV Splitter Source" still doesn't get used, there is probably a bug which is preventing dshow from finding it. The only way I can get dshow to use it is by forcing it's use by setting "Source Filter"="{B98D13E7-55DB-4385-A33D-09FD1BA26338}" at HKEY_CLASSES_ROOT\Media Type\Extensions\.ts for example.

Thats not a bug.
I just don't believe in screwing up the users DirectShow settings like Haali does, and inserting LAV Splitter as the absolute forced splitter. The player should manage which filter is used, and the user should have a choice. Haali doesn't give you a choice. If its installed, it forces every player to use it by setting special entries in the registry. There is no bug that prevents LAV from being used. If you use the LAV installer, it'll set those Source Filter registry keys for you.

In MPC-HC you can also just set Haali to blocked, which should work.


Also, the "LAV Splitter" and "LAV Splitter Source" have the same merit, which isn't good imo. I reccommend setting "LAV Splitter" to 0x00400000 merit as it is not the one that should be used. "LAV Splitter Source" is the one that shoud be used, that is if you can figure out what's wrong causing it to never get used.

The DirectShow "way" is to actually use File Source (async) together with a splitter filter. Not a source filter that does both. This works perfectly if you don't have a power hungry source filter that steals the show.


When LAV Video filter is installed, if you use Microsoft's Graphedit and go to Graph->Insert Filter... then try to expand Direct Show Filters, Graphedit will suddenly exit (it doesn't appear to crash).

Thats a bug in GraphEdit, nothing i can fix. Use GraphStudio.


Also a few feature requests, can we get a tray icon for the splitter? it really makes switching streams easier if you don't have to go through the player.

http://code.google.com/p/lavfilters/issues/detail?id=1


And what about supporting service/menu switching in TS files? Haali is the only one to support this IIRC. What I mean is, to switch to a secondary set of associated video/audio PIDs such as 1seg in japanese ISDB-T streams.
http://code.google.com/p/lavfilters/issues/detail?id=3