DirectShow和媒体文件

//=====================================================================
//TITLE:
// DirectShow和媒体文件
//AUTHOR:
// norains
//DATE:
// Monday 24-May-2010
//Environment:
// Windows CE 5.0
//=====================================================================

自从在blog上公布了CMedia的完全源代码后，就陆续接到不少邮件和提问，无非是询问CMedia能播放什么样的格式；或是破口大骂，将CMedia损得一无是处，因为该类什么视频文件都无法播放；当然也有好的，对CMedia赞不绝口，称其为万能的播放类。

为什么同样的源代码，却能得到如此截然不同的评论呢？有感于此，我觉得应该写一写这其中的奥秘了。

如果你是DirectShow的高手，那么你可以不必再往下看了，因为之后的内容没有足以让你深究的价值，仅仅是给初学者的扫盲而已--并且还是尽可能地简洁。

我们首先要知道，我blog上的CMedia其实只是对DirectShow在文件播放方面的一个封装而已，本质上还是彻头彻尾的DirectShow。

先简单地看一下DirectShow的最基础框架：

其实完整的框图不仅止于此，但那些对于我们从总体了解并无过多帮助，因此简略为此。

首先看一下框图最中间的"系统"。这个最好理解，也没什么可说的，就是我们的WinCE系统。

其次是调用者，即播放器，也就是我blog的CMedia。它通过一定的协议，向系统咨询媒体文件的播放。

最后是filter，其实际是解码器。能不能播放，播放的效果如何，都取决于该部分。

而这三部分之中，只有相邻的是可见的。比如播放器只知道系统，filter也只知道系统，而播放器和filter两者是无法互相知晓的。

那为什么同样的CMedia在不同的系统下播放的情况完全不同呢？

我们以一个非常简单的例子说明。

学校要举行校际比赛，需要找一个跑步跑得快的学生。体育老师走到班级A门口问："有谁跑步跑得快的？"没人回答。然后体育老师走到班级B门口问："有谁跑步跑得快的？"这时候小明站出来了。

对于这个例子，体育老师就相当于调用者，问话内容就是协议，不同的班级就相当于不同的系统，小明那就想当然的是filter。

体育老师（调用着）还是原来的体育老师，问话的内容（协议）也是相同的，但在不同的班级（系统），得到的结果是不同的（一个能满足要求，另一个则否）。

具体到文章最前面的情况，就很容易解释了。虽然是同样的CMedia代码，但在不同的系统里，因为所具备的filter不同，所以播放情形就迥然不同。

那系统的差异性是如何造成的呢？其实在系统编译的情况下已经决定了。在定制系统时，系统工程师有没有选择相应的filter，决定了你后期播放器的兼容程度。当然咯，这些filter在WinCE下是很少的，更多依赖的是BSP厂家的功力。

最后说一下，这个和网络上流行的TCP/MP是不同的。TCP/MP并不是采用标准的directshow，而是自己有解码库，是采用自己的库来解码的，完全不依赖于系统。这样有好处也有坏处，好处是播放的格式固定，在这个系统能解码，那么在另外一个系统自然也能工作正常；坏处是，很多BSP厂家都会根据自己硬件来做filter，以加快解码速度，而这些filter无法为其所用，造成同样的硬件平台，用TCP/MP播放会比用directshow播放更为不流畅。