While new NTFS Links propery page is looking for contained junction points, it shows an animated picture to indicate opertation in progress. The picture is a stock resource and is taken from shell32.dll resource type “AVI” name 150. It is an Audio Video Interleave (AVI) file embedded into binary resources as is.

What is however interesting is that being saved as a file and double-clicked, it appeared to be crashing the player process. What might go wrong with a stock resource, is it FFDShow again? This was the first guess and yes, it was FFDShow again. This is a “video only” file with video encoded with MS-RLE compression, FOURCC ‘RLE ‘. Microsoft provides a VCM codec for the format through msrle32.dll.

However, as already discovered, FFDShow register itself under extremely high merit and for this reason is preferred as a video decoder and attempts to handle the decompression itself. But it fails, and miserably enough to crash the hosting process.

The registration under unfairly high merit defeats the purpose of DirectShow’s powerful Intelligent Connect approach. “Why do you need a video decoder? You have FFDShow Video Decoder, forget about the others. Oops, sorry, I don’t like your file.”

Is there any way to stop the villain? Of course, there is.

To start, I tried to disable the decoder through FFDShow Video Decoder native interface and give it a last chance. Video decoder offers decoding properties to choose from, and it looked as if it can stop serving as decoder for the mentioned video format.

Still with the disabled settings, it kept unsuccessful attempts to decode and process crashes. So another workaround, and it is in fact a proper one, which should be done from the start (and I would also prefer that it was done by FFDShow itself), is to lower decoder’s merit to a level at which it would honor specialized decoders so that Intelligent Connect could fall back to FFDShow in case there is no bettter alternative. MERIT_UNLIKELY seems to be a good one for this codec:

This fixes the issue by letting DirectShow choose stock video decoder for MS RLE video encoding.

FFDShow is already known for it issues (including for example mentioned one). Today’s featured one is related to its Video Decoder. A great deal of FFDShow related issues amy be worked around with a single shot by listing the image name as an FFDShow exclusion under registry:

HKEY_CURRENT_USER\Software\GNU\ffdshow; blacklist

but I felt relaxed and the problem re-occurred from Windows service where HKEY_CURRENT_USER was not available/applicable.

FFDShow Video Decoder registration looks like:

It is immediately clear that the filter registered with extremely (and definitely unreasonably, breaking guidelines) high merit in conjunction with generic video media type will be taken as a possible decoder in every single graph rendered. At the very least, this is a perofrmance issue, similar to frequently reported like this recent one: How to reduce time during pin connection on vista ultimate using RenderStream function…?.

However the real problem was that the filter was accepting connection on my source pin and pretending it could be a valid decoder instead my own one (definitely registered with a proper merit of 0×00800000 (MERIT_PREFERRED). Did it actually decode? No, just sent blackness on the output… It seems that it is getting a good manner to distance from this crapware by implementing IAMGraphBuilderCallback interface on the graph builder site and reject consideration of FFDShow A/V Decoders as candidates.

Surprisingly fast I got new problems having ffdshow installed as a part of K-Lite Codec Pack. No wonder though because let us take a look at registration information:

Display Name: @device:sw:{083863F1-70DE-11D0-BD40-00A0C911CE86}\{0F40E1E5-4F79-4988-B1A9-CC98794E6B55}
CLSID: {0F40E1E5-4F79-4988-B1A9-CC98794E6B55}
Friendly Name: ffdshow Audio Decoder
Path: C:\Program Files\K-Lite Codec Pack\ffdshow\ffdshow.ax
Merit: 0x3fffffff

Nice merit, ain’t it? What is merit anyway? Let us check at MSDN:

MERIT_PREFERRED = 0×800000,
MERIT_NORMAL = 0×600000,
…
MERIT_HW_COMPRESSOR = 0×100050

The highest defined value is 0×00800000, while ffdshow is registered with 0x3FFFFFFF, that is on top of everything. No doubt the developers read Guidelines for Registering Filters and decided to get rid of the rest of installed software as unnecessary crap.

Anyway back to the problem: I had an A-law wave file (WAVE_FORMAT_ALAW) to play and make sure its data is valid and quite unexpectedly there was a silence while playing. A quick check confirmed that the sustem has CCITT A-law codec installed, however GraphEdit shown ffdshow Audio Decoder intercepting decoding. Obviously it spoiled the thing!

Finally I decided it was a right time to take an advantage of IAMGraphBuilderCallback interface to detect and reject the bastard.

Luckily it is much easier than it may seem:

CComQIPtr< IObjectWithSite > pObjectWithSite = pGraphBuilder;
__D(pObjectWithSite, E_NOINTERFACE);
CObjectPtr< CAmGraphBuilderCallback > pAmGraphBuilderCallback;
pAmGraphBuilderCallback.Construct();
__C(pObjectWithSite->SetSite(pAmGraphBuilderCallback));
__C(pGraphBuilder->Render(_FilterGraphHelper::GetFilterPin(pSourceBaseFilter, PINDIR_OUTPUT)));
__C(pObjectWithSite->SetSite(NULL));

CAmGraphBuilderCallback is active between SetSite calls and it is sufficient to throw ffdshow Audio Decoder away.

Partial (some header files are excluded) Visual C++.NET 2005 source code can be downloaded here.