The content here is mainly principles of the system, we look for the method of filter, using the pre-read file content to determine the method of the file type, etc., this understanding, many things are solved.
Registration file type
Give a file name, you can locate the source filter of its filtering graphic manager. This mechanism is a mechanism for system identification media types, you can also use this mechanism to register your file type. If you are registered successful, then when you call the iGraphBuilder :: Render method or the iGraphBuilder :: AddSourceFilter method, DirectShow automatically loads your registered source filters to play your file. At this time your file is part of the system.
In order to be positioned from the file name to the source filter, the graphics manager is filtered to try the following steps:
1, matching protocol
2, match file extension
3. Match typical byte data in the file, we call the test byte
protocol:
As if the FTP or HTTP protocol name is registered under the key value of HKEY_CLASS_ROOT, its registration method is as follows:
HKEY_CLASSES_ROOT
Source Filter =
Extensions
<.ext1> =
<.ext2> =
If the file name contains a ":" number, the filtering graphic manager will try to use the string in front of the colon as the protocol name. For example, if the file name is "MyProt: //myfile.ext", the system searches for MyPROT in the key value. If there is a match name, and in Extensions contains the sub-keys, the filtering graphics manager searches for full matching file extensions in the sub-key. The key value must be a string form of Guid, such as: {00000000-0000-0000-0000-000000000000}. If you can't find a matched subkey in Extensions, then it will look for a sub-key called: source filter, and this subkey is also a string form of GUID.
If matching is found, the filtering graphic manager uses this GUID to load the filter as the CLSID of the source filter. If you find it, you will use the File Source (URL) filter, such a file name is made by the system as a URL. There are two exceptions to the above situation:
A. In order to exclude misunderstandings of the drive name, the single byte before the colon does not do protocol processing.
B. If you are: "File:" or File: // we don't do it.
File extension
The filtering graphic manager query extension is in HKEY_CLASSES_ROOT / MedIA Type / Extensions / .ext /. Here .ext is the extension. If this key value exists, the Source Filter will contain the CLSID in the form of the source filter string. This key value If includes Media Type and Subtype, these two are the main types and subtypes of Guids.
Automation bytes
We can identify file types through partial data of offset addresses in some files. The filtering graphic manager will query the registration key in the following format:
HKEY_CALSS_ROOT / Media Type / {Major Type} / Subtype}
The main type Major Type and subtype Subtype is defined as a GUIDS that is used as media type. Each key contains one or more sub-keys, usually called: 1, 2, etc., these places are where the test bytes are defined. At the same time, Source Filter gives the CLSID of the source filter. A string containing four data segments is defined as the hypervisor by the sub-key. :
Offset, CB, Mask, Val
In order to match files, the filtering graphic manager reads CB bytes from OFFSET. Then perform an AND operation with Mask. If the result is equal to VAL, the file is considered to match. Mask and Val are given in 16-in-form. If Mask is empty, then we think it is a string of 1s of the CB length. If Offset is a negative value, it indicates that the offset begins to calculate from the end of the file. In order to correctly identify files, the DirectShow requires all values of sub-keys to match. Just like the following 0 and 1, you must confirm the file type: (this is the data under HKCR / Media Type)
{E436EB83-524F-11CE-9F53-0020AF0BA770}
{7364696D-0000-0010-8000-00Aa00389B71}
0 "0, 4, 52494646, 8, 4, 524d4944"
1 "0, 4, 4d546864"
Source Filter "{E436EBB5-524F-11CE-9F53-0020AF0BA770}"
In this example, the first key value is the main type MediaType_Stream. The subkey is identified by a child media type MediaTyPE_MIDI. The sub-key of the source filter is CLSID_ASYNCREADER, which is a File Source filter.
This method of identifying file types is very similar to the implementation of Win32's getClassFile.
The following example explains the representation of the test string:
0, 4, ABCD1234, -4, 4, ABAB00AB
This example indicates that the head 4 bytes of the file must be 0xAb, 0xcd, 0x12, 0x34, the last 4 bytes of the file must be 0xAb, 0xAb, 0x00, 0XAB.
If you find a matching file type, it will load the specified source filter, query the filter with the iFilesourceFilter interface, and then call the iFilesourceFilter :: Load method. The parameters in LOAD are file names and media types, which can already be found in the queries just now. If the filtering graphic manager does not find the corresponding information from the registry, it will call the Async File Source filter by default. In that, it will set the media type as MediaType_Stream and MediaSubType_none.
