DirectShow项目开发经验

来源：百度文库 编辑：神马文学网 时间：2024/04/25 21:13:46
DirectShow项目开发经验一、              开发环境开发平台：PPC/SP MicrosoftRWindows Mobile 5.0、MicrosoftR Windows Mobile 6.0；开发工具：Visual Studio2005；开发文档：magneto documentation may 18, 2006.chm，directshow.chm，WindowsMedia Player SDK。二、              Windows Media PlayerMicrosoft公司的WMP（Windows Media Player）对文件的播放提供了一套基于DirectShow的框架，而对于开发者而言，可以基于该原理来实现对本地、网络数据的不同处理。DirectShow主要包括三大功能模块，Source Filter负责解决数据来源，Transform Filter一般指各种Decoder Filter，实现数据的解码，Renderer Filter负责解码后数据的显示与呈现，即负责数据的“去向”。三、              LocalSource Filter（跳帧的实现原理）LocalSourceFilter一般包括推模式和拉模式，为了减少开发的工作量我们采取推模式，即该LocalSourceFilter一边从文件中读取数据，一边实现Audio、Video数据的分离，然后分别推送给各自的DecoderFilter，数据经过A/V分离后，在各自的线程中解码、显示，哪它们怎么达到A/V同步的呢？DirectShow确保A/V同步，主要是依赖于Sample（数据包）上的TimeStamp（时间戳），VideoRenderer根据其TimeStamp来安排何时进行显示，或者丢弃一些sample。由于我们的开放平台是WindowsMobile，其CPU的性能不高，一般在200~500Mhz左右，因此当播放一些high performance文件时，仅仅依靠VideoRenderer丢包处理是远远不够的，而必须需要Source Filter“早早”地进行数据丢包——跳帧。又由于Video Renderer依赖于流时间Stream Time 并比较TimeStamp来进行决策的，所以我们的Source Filter也必须参考Stream Time（Ts）这个“桥梁”进行跳帧处理。此外LocalSource Filter需要给将发送的sample打上时间戳，而该时间戳一般是从文件层（File Layer）获取的，这里不妨命名为Tf，另外跳帧后为了不引起花屏现像，我们必须选择key位置进行跳帧。这样一来需要综合考虑文件层key的分布情况：1．Key间隔不大，且分布比较均匀这种key分布是最为理想的，因为基本上任意点都可以作为跳帧点，这样LocalSource Filter随时可以在文件层获取一个与Ts匹配的Tf，这样发送出去的Samples很好地符合了Video Renderer的要求，也很好达到了A/V同步。2．Key间隔大，且分布不均匀这种情况较差，因为LocalSource Filter较难在文件层获取一个与Ts匹配的Tf，同时考虑到Video Renderer对Sample的处理，我们选择的跳帧点（Tf）不能偏离Ts太远，否则如果Tf>>Ts，那么Video Renderer将Hold住该Sample，画面表现为停滞一段时间；如果Tf<s，那么Video Renderer将丢弃一些Sample或者极快的进行显示，这样画面看起来滚动飞快。根据经验我们选择那些满足Tsfs+500ms的key点作为LocalSource Filter的跳帧点。这样A/V同步是暂时的，不同步是动态的，但总体说来基本能够满足A/V同步的要求，毕竟这类文件是比较少的。一种最差的情况是整个文件就一个key，对于该类型的文件只能是不同步播放了。另外Seek之后的Sample也需要作些特殊处理。Seek之后由于Sample的时间戳进行了突变，DirectShow的流时间也会有一个动态调整来确保Stream Time与新起始的Sample时间戳相吻合。但由于VideoSeek要求文件的key点，这样与实际得到的位置有一个偏差，一般我们采取超前请求点Seek 关键帧。这样得到的Samples对于VideoRenderer而言是“迟到”的。所以LocalSourceFilter需要对这些Samples作特殊处理以“决定”是否丢弃（比如处理后的TimeStamp <0就应该直接丢弃，以免图像过快播放）。四、              网络接收NetSource Filter目前我们的项目采用rtsp协议进行网络数据的接收，由于客户端采用WMP，这就涉及WMP基于rtsp://的url来Load NetSource Filter，以及当网络Buffer数据时怎样与WMP进行“对话”的问题。首先通过查阅Windows Media Player SDK，我们可以修改注册表如下：       [HKEY_LOCAL_MACHINE\Microsoft\MediaPlayer\Player\Schemes\rtsp]       Runtime = 7             //Render using Microsoft DirectShow.       Permission = 31                    这样我们的NetSource Filter就可以被WMP通过rtsp://的url来load了。下面看看当NetSource Filter在Buffer数据时，怎么“通知”WMP的。我们知道WMP是通过创建FilterGraph来管理各种Filters，这样当Buffer数据时，NetSource Filter必须向FilterGraph发送EC_STARVATION消息，即“告知“FilerGraph当前的Filter转换到了一种新的状态，要求上层应用程序等待该转换过程。同时WMP接收到EC_STARVATION消息后会不断调用NetSource Filter的GetState接口来查询其状态是否转换完成。这就要求我们虚继承该函数，当Buffer数据时，直接返回VFW_S_STATE_INTERMEDIATE（The state transition has not completed）否则返回S_OK表明转换完毕。从而在用户看来当网络Buffer数据时，其进度条是暂停的，当数据足够时，进度条又继续前进了。LiveSource中Pause/Resume问题的解决。当NetSource Filter接收广播数据时，我们碰到最棘手的就是播放过程中怎么解决用户的Pause/Resume问题。由于底层库没有提供针对LiveSource源的Pause功能，即用户Pause一段时间后，继续播放时，其图像应该是同步于服务器的。所以我们只好在Pause时“人为”地断开RTSP的连接，继续播放时重新建立连接，采取这种绕的方式来达到LiveSource中的Pause/Resume功能。由于这种“Pause”的实现违背了DirectShow的基本原理，即Pause时数据线程被强行Stop掉了。因此在深入研究DirectShow Push Source框架和多次试验后，我们做出了这样的特殊处理：当用户Pause时，我们一方面Stop掉RTSP的数据连接，同时确保Audio/Video Pin中各自线程的正常运行，当用户执行Resume操作时，我们在Audio或者Video Pin的线程中进行RTSP的Reset重连接操作，最后由于RTSP Reset后Video/Audio Sample的时间戳复位了，为了保证画面的连贯性，我们必须给Reset（Resume）后的Video/Audio Sample加上Pause时各自的时间戳（作为偏移量）。  五、              Decoder FilterDecoder Filter的开发比较简单，一般都是跟踪调试一些解码Crash的问题。比如：内存越界、解码容错处理、Seek或者Flush后对头信息的解析处理等等。六、              Video RendererVideo Renderer在我接手开发时已经比较完善了，我主要解决了一些刷新问题。比如全屏后不能返回到正常模式，Stop后WMP又Repeat播放起来等等问题。七、              Muxer FilterMuxerFilter实现时，也时碰到了类似LiveSource的Pause/Resume的问题。当时由于MuxerFilter接收的Sample只有Audio打上了绝对时间戳，Video的是相对的。如果用户执行了Pause/Resume操作，就给我们Dump文件时带来了一定的困难，因为Resume后这些Sample需要减去Pause->Resume段内时间戳的累积，否则播放该文件时要么黑屏，要么A/V不同步。因此Resume后DumpVideo时必须参考Audio来计算Pause->Resume的时间段了，这里不妨记为DeltTa，这样需要考虑以下几种情况：1．Resume后Video Sample先到达Muxer如果Video Sample先于Audio到达Muxer，由于这时我们没法从Audio中得到正确的DeltTa，因此我们只好在Pause时刻的基础上加上一个默认值（比如100ms）作为Resume后那些先于Audio的Video Sample的起始时间戳。2．Resume后Audio Sample先到达Muxer如果Resume后有太多的AudioSample先于Video到达Muer，我们需要给Resume后第一帧的VideoSample的时间戳进行调整，否则播放该文件时会出现某处被卡住的现象。Resume后接收到的第一帧Video Sample经由DeltTa的偏移调整后，还比Pause的时刻滞后许多（比如大于1秒），我们需要对其作特殊处理，确保与Pause的时刻点连贯起来——在Pause时刻基础上加上500ms的偏移作为新的起始时间戳。八、              小结我们这个DirectShow项目的开发是在既定的框架下，所以需要做好的工作往往是一些细节方面的处理，以及探索、熟知Windows MediaPlayer应用层如何通过Graph这个桥梁与各种Filter进行交互的，还包括熟知一些注册表信息的特殊功能。而涉及到Filter本身功能的开发一般都比较顺利，项目往往是卡在Filter与Windows MediaPlayer打交道的处理上。WMP应用层对于DirectShow的处理并没有详细的官方资料，所以我们往往是通过两头“凑”的方法来进行探索的，即一方面查阅DirectShow的资料，一方面查阅WMP SDK，同时进行许多试验和经验总结，来积累一些它们之间相互处理的一些具体细节过程。
DirectShow项目开发经验 利用 DirectShow 开发自己的 Filter 基于AMD Au1200在PMP项目中的开发经验－ DirectShow学习指南之数据流结束通知_VC开发_开发语言_软件开发_天新网 使项目开发自动化 项目开发管理经验交流 magic项目开发规范 项目开发管理经验交流 开发与项目管理 上海房地产项目开发流程 市场开发实战经验 程序开发经验 Android开发经验分享 软件开发的项目管理 项目开发经验谈（一） IT项目开发管理守则 ASP.NET项目开发计划 旅游开发项目盈利模式分析 旅游开发项目盈利模式分析 系统开发的项目规划 ASP.NET项目开发计划 MIS系统开发中的项目 一个项目的开发流程 arm开发经验笔记(ZT)