多媒体流.doc

Introduction This article discusses synchronization mechanisms under DirectShow (part of the DirectX Media SDK) in order to play a video stream synched with the audio stream. The article provides custom solutions for that purpose, using the Microsoft Foundation Classes framework. Playing a video stream on a standard PC computer is not something easy natural. If the video stream is encoded with a frame rate of say 25 images a second, one can not say that a given PC is able to play the stream on screen really at this rate. Whether we are talking about an old PC, a Pentium based, or recent PCs, having in hand more horse power means moving the problem, not solving it. Indeed, a PIII based PC is very likely to be able to play the stream at such rate, but whether youre doing something else at the same time, say compile a source code, processing something in the background, and so on, the computer will drastically lose performance. Core mechanisms in DirectShow are designed to undertake this issue. The more politically correct solution, and by the way working solution, is to try to play the video stream as fast as possible, being synch with the audio stream, and drop any image from the video stream whenever it loses synchronization with the audio stream. In this article, we are to talk with different point of views about synchronization mechanisms and by the way provide custom solutions, including or not multithreading. Solution #1: using CWinApp::OnIdle from the MFC framework. Solution #2: using asynchronous notifications through a custom video renderer filter Solution #3: using asynchronous streaming through multithreading Why video loses synchronization with audio Its well known that audio decoding needs less CPU time than video decoding. Its because for a specific time duration, there is much more data to decode in the video stream than in the audio stream. Thus, whenever there is a lack of synchronization between the video and the audio stream, its very likely