DirectShow和媒体文件

转载自:http://blog.csdn.net/norains/archive/2010/05/24/5619451.aspx

 

 

 

自从在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播放更为不流畅。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值