Registering a Custom File Type

This topic describes how to register a new file type so that file-reader source filters can recognize it. The mechanism used here is taken from the GetClassFile function, which is used to return the CLSID associated with the given file name. DirectShow media types use the same quadruple set of values in the registry that are used for GetClassFile FileType registrations, but associate a file matching this criteria with a media type rather than a file type. Also, the registry entry for a DirectShow media type provides the CLSID of a source filter that can be used to read this media type.

For both FileType and MediaType registration, a pattern in the registry contains a series of entries of the form.

regdb key = offset, cb, mask, value  

The media type is defined as a CLSID pair, {Majortype clsid, Subtype clsid}. If the data in the file at the specified offset or offsets matches a pattern in HKEY_CLASSES_ROOT\Media Type\{<major type>}\{<subtype>}, the media type CLSID pair associated with that pattern is the media type of the file.

The parameters of the registry key are interpreted as follows. The value of the offset item is an offset from the beginning or end of the file, and the cb item is a length in bytes. These two decimal values represent a particular byte range in the file. (A negative value for the offset item is interpreted from the end of the file.) The mask value is a hexadecimal bit mask that is used to perform a logical AND operation, with the byte range specified by offset and cb. The result of the logical AND operation is compared with the value item. If the mask is omitted, it is assumed to be all ones. The number of hexadecimal digits in mask and value must be twice the value of cb (because cb is in bytes).

Each pattern in the registry is compared to the file in the order of the patterns in the database. The first pattern where each of the value items matches the result of the AND operation determines the media type of the file.

Note that each entry can have multiple quadruples, all of which must match the data in the file for the media type to be associated with the file. An example of using multiple quadruples in a single entry might be to match the byte sequence at the beginning and at the end of the file. The following example shows a pattern of AB CD 12 34 as the first 4 bytes in the file and AB AB 00 AB as the last 4 bytes in the file (no masks applied here). All elements must match for the pattern to match a file with a media type.

0 = REG_SZ 0, 4, , ABCD1234,  -4, 4, , ABAB00AB 

Additionally, there can be multiple entries specified under a single media type, a match to any one of which will associate the file with the media type.

For example, the pattern contained in the following entries of the registry requires that the first three bytes be AB CD 12, that the fourth byte be 32, 33, 34, or 35, and that the last 4 bytes be FE FE FE FE.

HKEY_CLASSES_ROOT
    Media Type
         {12345678-0000-0001-C000-000000000095}
                {87654321-0000-0001-C000-000000000095}
                    0 = REG_SZ 0, 4, FFFFFFFE, ABCD1234, -4, 4, , FEFEFEFE
                    1 = REG_SZ 0, 4, FFFFFFFE, ABCD1232, -4, 4, , FEFEFEFE
                    Source Filter = {56781234-0000-0001-C000-000000000095}

If a file contains such a pattern, the media type {12345678-0000-0001-C000-000000000095}{87654321-0000-0001-C000-000000000095} will be associated with this file. The file source filter for the media type is identified by the CLSID of the Source Filter value under the key for the media type.

The media type can be used to find filter handlers for the file in order to render it. A handler for a type performs a more exact test of the file to be sure of the type before attempting to render the data.

Note that this scheme allows for a set of alternative masks (for instance, .wav files) that might or might not have a RIFF header.

Registering File Extensions Without Byte Extensions

As mentioned previously, you can register a particular media type/subtype pair or a source filter CLSID for a given file extension. In this case, only the type and source filter will be used to read the media type. However, if you register your own source filter, there is no requirement for the name to represent a real file because the name gets passed to the source filter for interpretation.

The registry entries are as follows.

HKEY_CLASSES_ROOT\Media Type\Extensions

As an example, if the file extension was xxx, then the key would have the following structure.

.xxx
REG_SZ: Media Type
REG_SZ: Subtype
REG_SZ: Source Filter

Each value represents a GUID.

Last updated on Wednesday, April 13, 2005

© 2005 Microsoft Corporation. All rights reserved.