引言
AVS 是我国具备自主知识产权的数字音视频编解码标准。除了视频和音频等基础信源编码标准外，AVS中还包括有系统、IP网络传输、文件格式等一系列支撑标准。在提供相同编解码质量的条件下，AVS视频[1]的压缩效率可达到传统 MPEG -2标准的2～3倍，与国际上最新的H.264标准基本处于同一水平，而算法的实现复杂度却大为降低。此外，低廉的专利使用费也是AVS能够吸引产业链中各环节用户所关注的一大重要亮点。
近年来，随着宽带互联网及其应用的快速发展，越来越多的用户采用P2P等技术通过互联网下载视频文件进行观看，或者直接以流媒体的方式在线收看视频节目。然而，在目前通过互联网广泛传播的音视频媒体内容中，绝大部分采用的依旧是wmv、real、MPEG4、H.264以及flv等编码格式，AVS几乎难觅踪影。究其原因，除了以AVS编码的节目源内容较为匮乏之外，由于目前绝大多数媒体分发工具(如P2P流媒“十一五”国家科技支撑计划项目资助，编号：2006BAH02A10 体软件等)仅关注于从网络的角度来提高媒体分发的效率，在客户端一般采用现成的第三方播放器和解码库来进行媒体播放，因此缺乏合适的AVS播放器也就成为了阻碍AVS被广大互联网用户所熟悉和接纳的一个重要因素。
客户端 媒体播放器 是将音视频媒体信息最终展现给用户的窗口，是音视频流媒体业务实现中必不可少的一个重要环节。为了推广和普及AVS应用，培育AVS互联网用户群，为客户提供完美的视听觉体验，本文设计并开发了一套基于Windows平台的AVS流媒体播放器，能够全面支持各种文件封装格式和网络传输条件下的AVS媒体播放。
1 开发与运行平台
为了提供良好的开放性和可扩展能力，我们选择采用 DirectShow 架构来开发AVS播放器。
DirectShow是微软公司提供的一套基于COM(组件对象模型)编程接口的开放性应用框架，能够为Windows平台上各种多媒体应用系统开发提供完整的解决方案[2]。
基于DirectShow开发的应用系统由一系列独立注册的模块化COM组件所组成，在DirectShow中通常称之为插件(fiLTEr)。多媒体数据的处理过程被分成为若干步骤，每一步由一个插件来完成。为了在插件之间传递数据，需要将若干插件相互连接起来，一个的输出作为另一个的输入。以这种方式连接在一起的一组插件称为插件图(Filter Graph)。在插件图中，媒体数据以样本(sample)为单位在插件之间进行传递和处理，从源插件(source filter)经由中间插件最终流动到呈现插件(rendering filter)，从而实现媒体播放。对于视频来说一个样本通常对应一帧视频数据。
不同DirectShow插件之间的相互连接和数据传递是通过插件上的插头(PIN)来具体实现的，分为输入插头(input pin)和输出插头(output pin)两种类型。上游插件的输出插头与下游插件的输入插头连接在一起。连接的过程实际是一个媒体类型协商的过程，通过比较两个插头上记录的可支持媒体类型，最终确定一个双方都支持的类型，这样就能够保证下游插件可以处理从上游插件接收到的数据。
DirectShow插件以及插件图的管理是由一个更高级别的插件图管理器(Graph Manager)来完成的，它提供对插件图中媒体数据流的各种播放控制和管理。对于插件图的建立，可以在插件图管理器中控制每一个插件的加入，也可以通过智能连接的方式。DirectShow中的智能连接会首先根据文件名或者网络协议名来查询注册表，得到source filter并将其加入插件图。然后再根据插件的输出pin上记载的媒体类型逐个尝试下一个可用的插件。依此类推，当所有插件的输出pin都和其它插件的输入pin建立好连接之后，就完成了插件图的创建过程。
按上述方式开发的AVS播放器由一组DirectShow插件所组成，它提供了一套驱动媒体播放的内核而本身并不带播放界面。在实际运行中不仅可以与任何支持DirectShow的通用播放器外壳程序(例如WindowsMedia Player)配合使用，同时还支持第三方软件开发者在此基础上定制开发自己特色的播放器界面，因此具有很好的开放性、适应性和可扩展性。
2 总体架构设计
AVS播放器应能够支持两种形式的媒体播放：本地文件播放和网络流媒体播放。
对于本地文件播放，AVS目前主要存在两种文件封装格式：
1）AVS-P1(AVS第一部分：系统)[3]中所定义的兼容于MPEG2系统的TS流封装格式，文件后缀名为.avs，简称TS流文件。
2） AVS -P9(AVS第九部分：文件格式)[4]中所定义的流媒体文件格式，文件后缀名为.asm(AVSStreaming Media)。该文件格式继承并兼容于国际标准ISO基媒体文件格式(ISO/IEC 14496-12 | 1544412)[5]，其中采用了面向对象的数据组织和存储格式，可容纳和复用多种不同的具有时间信息的媒体流，其中每个媒体流以一个媒体轨道(media track)的形式存在，不同媒体轨道中的样本数据通过时间戳来进行同步。为了指导流媒体服务器对文件进行流化处理(通过IP网络传送)，在该文件格式中还可以为每一个媒体流创建一个提示轨道(hint track)。
对于IP网络播放，AVS中采用了与ISMA(国际互联网流媒体联盟)[6]相兼容的流媒体体系结构。其中采用SDP协议[7]来描述和发布流媒体会话，采用RTSP协议[8] 来进行流媒体会话控制，采用RTP协议[9]来实际承载和传输流媒体数据。在AVS-P8(AVS第八部分)[10]中规定了在IP网络上传输AVS流式媒体时所采用的RTP净载(payload)格式。
在一些早期的流媒体系统中，服务器简单地通过web方式发布媒体文件，客户端采用HTTP下载以及文件缓存的方式来实现边下载边播放。鉴于其实现的简单性，目前市场上仍存在不少类似这样的系统，例如许多P2P流媒体点播系统就采用这种下载后缓存的方式来实现媒体播放。为了适应不同应用的需求，我们的AVS播放器也需要提供对这种播放模式的支持。
综上考虑，基于 DirectShow 插件图模式所设计的AVS播放器总体架构如图1所示。
图1中存在两个source fiLTEr：RTSP source filter和File/HTTP source filter。其中RTSP source filter用于网络流媒体播放，负责通过RTSP协议与流媒体服务器建立会话连接、从中接收RTP形式的音视频数据包，并将解包后的数据重组为视频帧和音频帧后分别传递至后面的视频和音频解码filter。
File/HTTPsource filter用于本地文件播放和基于HTTP的网络文件播放。对于本地文件播放，该source filter根据文件封装格式(asm或TS)来决定在插件图中下一步该与哪个splitter filter建立连接，并将读取的文件内容传递至它所连接的splitter filter进行音视频分离。对于网络播放，该filter所实现功能与本地文件播放类似，只不过多了一个预先采用HTTP协议从web服务器读取媒体数据并缓存于本地临时文件的过程。
在File/HTTP source filter之后可连接两个splitter filter。其中asm splitter filter用于解析符合AVS-P9封装格式的asm媒体文件数据，从中分离出视频帧和音频帧之后分别送往相应的解码filter。TSsplitter filter的功能与asm splitter filter相似，只不过解析和分离的是符合AVS-P1封装格式的TS流数据。
AVS视频解码filter是实现AVS视频播放的一个关键组成部分。它负责从上游source filter或splitterfilter处接收AVS视频帧数据，然后调用AVS视频解码库将其解压缩为原始视频帧数据后提交视频呈现filter送显卡播放。将AVS解码库与解码filter分离并定义规范的调用接口，有利于解码库的升级与重用，开发者和用户可以根据需要选用或开发不同版本的解码库。
音频解码filter与视频解码filter类似，负责从上游source filter或splitter filter接收音频帧数据，经解码后提交至音频呈现filter送声卡播放。
3 播放器实现
本节主要以RTSP网络流媒体播放为例简要描述AVS播放器的工作流程和实现技术，包括播放器与流媒体服务器的交互以及播放器内部的流水线处理过程。
通常存在两种形式的流媒体播放：点播和广播(直播)。在点播模式中，客户端直接请求播放存放于流媒体服务器中的某个文件，在播放过程中还可以执行暂停、拖拽、快进、快退等操作。点播时使用的URL形式为：RTSP://servername/abc.asm，表示采用RTSP协议向域名为servername的服务器请求播放abc.asm文件。在广播模式中，服务器将所有节目内容划分为不同的频道，每个频道按照预先规划好的时间表定时播出相应的节目内容，客户端一旦选定某个频道之后，便只能被动接收和播放该频道目前正在播出的内容而无法执行进度条拖拽等交互式操作。直播时使用的URL形式为：RTSP://servername/abc.sdp，表示采用RTSP协议向域名为servername的服务器请求播放由abc.sdp文件所描述的频道内容。
如图2所示，播放过程由播放器接收到来自用户（应用程序）的URL请求开始。Graph Manager根据URL中的RTSP协议名加载注册表中与之相关联的RTSP source fiLTEr。RTSP source filter被加载后，首先与流媒体服务器建立连接，然后通过RTSP协议与之进行交互。在RTSP交互过程中均采用“Send-and-Get”方式：每次发送完一个请求后就等待服务器的应答，根据应答的内容再发起后续的请求。通过RTSP协议启动一次与流媒体服务器的会话需要经过三步交互，分别为发送和接收DESCRIBE、SETUP和PLAY消息，如图2中左侧所示。
本文关键字：播放器 综合-其它，单片机-工控设备 - 综合-其它
上一篇：一种基于PC机的数字电视接收系统
