The Windows Media media content uses the ASF file format. Microsoft provides Windows Media Format SDK to support the following three functions: ASF file generation (including ASF data fluidization), an Asf file editing and playback of ASF files (including ASF media stream playback). Before starting programming, there is an overall understanding and understanding of the SDK system. (Note: If it is not specified, the SDK or WMF SDK described in this book refers to Windows Media Format SDK.)
The WMF SDK uses object-oriented design, a set of advanced development kits that are based on COM component models. Here, the advanced, means that the SDK shields the ASF data format, the network transmission control, etc. The underlying streaming technology is detailed, and only the upper layer programming interface is left to the developer.
Figure 2.1 WMF SDK system structure
As shown in Figure 2.1, SDK introduces a series of objects, such as generators, readers, editors, and the like. It is these SDK objects to block the details of Windows Media technology, so that application developers do not need to understand too much streaming media underlying technology, and also develop very professional streaming media applications.
Among the many objects introduced in SDK, the most important thing is the three listed in Figure 2.1. The generator is typically used to encode non-compressed media data into data in Windows Media format. The entire encoding process is very simple, as long as you configure the target data stream format through an object called Profile, then tell the generator in the format of the input data, and then pass the input data to the generator in the established manner, the rest is It can be handed over to the generator. The generator will automatically select a Windows Media encoder according to the configuration of the Profile, and then compress the input data, and complete the package, finally write files or streamline.
Figure 2.2 Workflow of the generator
Figure 2.2 is a substantially workflow of the generator. It can be seen that there may be a pre-processing process inside the generator to input data. Because the data format that the particular encoder can accept is always limited. If the input data format cannot be accepted by the encoder, a pre-processing process is automatically performed inside the generator. These preprocessors include video size zoom, frame rate adjustment, color spatial conversion, watermark, and sample frequency conversion, etc.. In addition, the generator itself is not responsible for the ultimate goal of the encoded data, but handles this task to a target called the receiver (SINK), such as being saved as a file, handed over to the file receiver. The network receiver can broadcast the data, and the data can be distributed to the server that can be distributed to the server running Windows Media Services. SDK uses this "builder receiver" design to be advanced, which guarantees that the SDK system has strong scalability. For example, we can develop your own receiver, determine the ultimate goal of compressed data according to our requirements.
If you use Microsoft's officially released Windows Media Encoder, don't doubt, through WMF SDK's learning, you can also develop a similar encoding software.
WMF SDK has two readers: asynchronous readers and synchronous readers. The functionality of the two readers is similar, which is used to read the ASF data. Different are their working methods: the asynchronous reader comes with a thread to push the data to the application; and the interior of the sync reader There is no drive of the thread that drives the data stream, the application is directly (in the thread of the application), through the interface function on the reader. (Note: Asynchronous readers are generally referred to as a reader, but only emphasize the "asynchronous" feature when compared with the synchronous reader.)
Figure 2.3 Reader Workflow By default, the reader outputs data of a non-compressed format. That is, the inside of the reader automatically selects the appropriate decoder to decompress the ASF stream data, as shown in Figure 2.3. Of course, by appropriate settings, the reader can also output the original compressed format of the ASF stream data.
It is worth noting that asynchronous readers can be used in the SDK of each version; and the sync reader begins in the 9 series SDK. The reason why the synchronous reader is added because the synchronization read mode of the data is more advantageous in some special occasions. For example, in some applications that perform content editing, use the sync reader quickly read part of the specified location. data. In addition, the synchronization reader is used to provide data by a direct interface function call, which is relatively simple. Of course, the synchronous reader also has a significant shortcomings, such as do not support reading network files, do not support DRM (Digital Rights Management), etc. Therefore, an asynchronous reader is used in the case where most ASF files are read.
Finally, let's briefly introduce the editor. Say is the editor, you don't mistake it to make changes to the media content. In fact, it can only edit some metadata. The so-called metadata is the title, description, author, copyright, etc. of this media content.
