您当前的位置:五五电子网电子知识单片机-工控设备综合-其它AVS媒体播放器设计与实现 正文
AVS媒体播放器设计与实现

AVS媒体播放器设计与实现

点击数:7789 次   录入时间:03-04 11:47:46   整理:http://www.55dianzi.com   综合-其它

  DESCRIBE用于向服务器发送所请求节目的URL,然后等待返回该节目所对应的SDP媒体描述信息。对于广播模式,服务器直接从URL所指定sdp文件中读取SDP信息返回;对于点播模式,服务器需要从URL所指定的asm文件中提取SDP信息返回。

  RTSP source filter在接收到DESCRIBE应答消息之后,首先解析其中的SDP信息,然后根据所包含各媒体轨道的编码类型来分别加载和连接相应的解码filter。对于 AVS 视频来说,所连接的解码filter是AVSvideo decode filter。AVS video decode filter加载之后,一方面根据从SDP信息中解析出来的视频序列头信息创建并初始化AVS解码库(AVS video decoderlib),另一方面进一步根据媒体类型加载并连接videorendering filter。至此,用于视频轨道媒体播放的Filter Graph构建完毕。音频的情况与此类似,不再重复。

  在完成Filter Graph构建之后,RTSP source filter根据从SDP中解析出来的媒体轨道等信息,向服务器发送SETUP命令,请求服务器为本次会话分配相关资源。在收到SETUP应答之后,RTSP source filter进一步发送PLAY命令,请求服务器开始各媒体轨道数据的传输。

  流媒体服务器在接收到来自播放器的PLAY请求后,随即进入数据传输状态。对于广播模式,服务器直接向播放器依次转发后台缓冲区中当前频道所对应的RTP数据包。这些RTP数据包可能直接来源于AVS实时编码器,也可能来源于上一级流媒体服务器,或者来源于播放列表中预编码存储的asm文件。对于点播模式,服务器需要首先打开指定的asm文件,从音视频媒体轨道中分别读取数据,然后根据各自所对应的提示轨道信息进行RTP打包之后再向客户端播放器进行发送。

  RTP数据包的传送既可以承载于UDP也可以承载于TCP,这是由播放器向服务器发送SETUP命令时所携带的相关信息决定的。当使用UDP承载时,音视频RTP包分别发送至客户端的不同UDP端口,分开处理,互不干扰。当采用TCP承载时,在服务器端首先需要将音视频RTP包数据与RTSP消息一起交织为一路字节流,然后再通过已建立的用于传送RTSP消息的TCP链路来进行传输;在客户端需要对收到的字节流进行解复用。

  RTSP source filter在接收到来自服务器的RTP包之后,首先根据媒体所对应的RTP净载格式进行解包,拼装为一个个的视频帧或音频帧之后再向下游的解码filter传递。

  AVS video decode filter每次从上游filter接收到一个完整的视频帧后,首先调用AVS video decoderlib进行解码,然后将解码结果发送至下游的videorendering filter进行显示。至此,一帧数据完成了它从流媒体服务器到客户端显示器播放的整个生命周期。

  在播放的过程中,用户可以执行暂停、进度条拖拽等操作。这是通过RTSP会话交互来完成的。以暂停操作为例,当用户点击“暂停”按钮时,GraphManager首先向rendering filter发出PAUSE命令,然后从rendering filter开始在Filter Graph中沿着与数据传输反方向的路径依次向上游filter传递该PAUSE命令,直到source filter。当RTSP source filter收到该PAUSE命令后,它便通过RTSP协议向流媒体服务器发送PAUSE命令,请求服务器暂停发送RTP数据包。当用户重新点击“播放”按钮后,各filter的响应流程与此类似。



www.55dianzi.com

   为了实现播放时的音视频同步,在整个流媒体数据的传递过程中,都有时间戳信息与之相伴。在 AVS 编码器或流媒体服务器最初生成RTP数据包时,在包头中都打上了一个时间戳信息。该时间戳从一个随机数开始,按照实际采集的时间依次递增。RTSP source fiLTEr在第一次接收到RTP数据包时记录一个初始时间戳,然后在接下来的播放过程中用当前RTP数据包的时间戳减去初始时间戳来计算其所承载音视频帧的时间戳。随后的音视频同步由 DirectShow 内部机制来实现,它使用了一个参考时钟,播放开始时值置为零。当带有时间戳的音视频帧到达rendering filter时,根据这些时间戳信息和参考时钟一起来决定何时播放该帧。当在点播中发生进度条拖拽操作时,系统参考时钟会被重置为零,同时重新记录RTP初始时间戳。

各种播放操作对于不同视频序列的响应时间

  4 性能测试与评价

  我们通过观察和记录在播放器中执行各种播放操作时的CPU负载、内存占用和系统响应时间等参数来对AVS播放器的性能进行简单的测试和评价。这些操作主要包括:打开媒体文件/URL、正常播放、停止、暂停、继续和拖动等等。此外,我们还通过监测24小时连续播放AVS节目时的CPU负载来对播放器系统的稳定性进行评价。测试用机器配置为Intel Pentium(R)Dual CPU 1.80 GHz,2 GB内存,流媒体服务器采用Darwin Streaming Server,网络环境为100 Mb/s局域网。测试用AVS视频序列如表1所示。

测试用视频序列

  不同视频序列在各种播放操作下的CPU和内存占用情况分别如图3和图4所示。从图中可以看出,在正常播放非高清节目时,内存和CPU开销都维持在较低水平;即使对于高清节目,CPU的占用率也在70%以下,内存占用不足60 MB,能够满足普通用户的播放需求。

  表2所示为各种播放操作对于不同视频序列的响应时间。从中可以看出,无论是打开本地文件还是通过RTSP协议远程打开网络点播源,都能在较短时间内转入正常播放,响应时间为2~3秒。对于停止、暂停、继续以及本地文件播放时的拖动操作,都感觉不到明显的停顿,响应时间几乎可以忽略不计。对于点播中的拖动操作,由于所采用流媒体服务器不支持对关键帧的定位,因此响应时间略有增长,但也基本控制在3秒以内。

各种播放操作对于不同视频序列的响应时间

  图5记录了24小时连续播放高清视频M3的CPU占用情况。从中可以看出,在较长的时间段内CPU占用率变化不大,基本维持在55%左右。在末尾一段时间CPU占用率有所波动,这主要是因为在播放的同时执行了其它操作而造成的,属正常行为。该测试说明播放器具有很好的稳定性,在长时间播放情况下不会出现程序崩溃等现象。

24小时连续播放高清视频M3的CPU占用情况

  5 总结

  开发基于PC机平台的AVS软件播放器有利于AVS在互联网流媒体应用领域的推广和普及,宣传并扩大AVS的影响面,提高广大互联网用户对于AVS的认知度。本文系统介绍了AVS播放器的开发背景、开发与运行环境、总体架构设计以及具体实现流程。所开发AVS播放器软件已经在互联网上得到了实际应用,用户可通过访问网址 http://www.avsvod.com 免费下载。



上一页  [1] [2] 


本文关键字:播放器  综合-其它单片机-工控设备 - 综合-其它

《AVS媒体播放器设计与实现》相关文章>>>