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.
Directshow is overkill for displaying the animation. It should be using the much simpler shell animation control. Its documented at http://msdn.microsoft.com/en-us/library/aa925106.aspx. It was covered in the old new thing blog at http://blogs.msdn.com/oldnewthing/archive/2005/02/16/374397.aspx.
Shell animations are in AVI format, for which DirectShow has parse and decode filters. In the GUI the animation is displayed using standard Windows control (exactly the one you provided MSDN links to).
The point was that ffdshow claims it can decode this format and registers on top of everything to intercept decoding (that is it will be called when you double click the .AVI file), however on real decoding it crashes together with the hosting process.
I made no attempt to display shell animation using DirectShow, if you meant that.
Did you also try the “Merit” slider on the “DirectShow control” page of the FFDShow property page? It allows you to adjust the merit and save the change in the registry.
I agree, though, that the default should not be set so high.
Yes, this puts it back to what it should be by default. But the point is that it is installed on multitude of computers, where 99% of people don’t even know what merit and property pages are. The default setting needs to respect existing guidelines to avoid compatibility issues.