Fooling Around

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.

Continue Reading »

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: 0×3fffffff

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 0×3FFFFFFF, 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.

Continue Reading »