网络视频点播系统方案.doc

网络视频点播系统方案 天津大学郝明哲臧萍侯正信 摘要 本文提出了一个适用于在局域网内使用的网络视频点播（VOD）方案。该系统采用了 P2P、 完成端口等新技术，大大提高了 VOD系统的效率。 关键词视频点播（VOD） MPEG-4 RTP DirectShow完成端口 流媒体 1引言 随着信息需求的不断深化，多媒体信息服务特别是视频和音频信息的点播服务引起了人们极大 的兴趣，交互视频服务已变得越来越普及。存储技术、通讯技术和视频压缩技术的高速发展，使得 基于IP网络的流媒体视频点播技术成为研究的热点。 ■a流式媒体技术是一种传送时间连续的音/视频媒体数据的新技术。流式传输时，用户只需要经过 数十秒的启动延时，就可以一边下载一边连续播放，克服了用户必须等待整个文件全部下载才能观 看的缺点。 ■a 2 VOD系统框架 本文提出的网络视频点播系统采用最通用的服务器一客户机模式。在此模式中，服务器首先启 动，等待用户点播；客户机通过网络访问服务器资源，完成相应的操作。 服务器端 服务器端 图1 VOD系统总体框架 图1示出了该网络视频点播系统的总体框架。VOD服务器主要由三大功能模块组成：预览片传 送控制模块、控制命令处理模块和多线程服务模块。 预告片的传送采用了以面向连接的TCP,基于HTTP协议的顺序流传输方式。顺序流式传输是 顺序下载，在下载文件的同时用户可观看在线媒体。在给定时刻，用户只能观看已下载的部分，而 不能跳到还未下载的部分。这种传输方式适合于发布无损下载的质量较高的视频片段，如片头、片 尾和广告等预告片文件。预告片的传输没有放到为相应客户创建的传送媒体数据的服务子线程中， 而是采用HTTP传送，为每个与服务器进行连接的客户请求单独创建线程。预告片相对于媒体数据 来说数据量小很多，服务器的响应时间不会太长，不会占用服务器的线程资源太久。由于预告片与 媒体数据的传送分离，在不选择预告片的情况下是对服务器资源的一种节约。 在点播过程中，服务器与客户端通信所要交换的控制命令，如Cmd_PrograitiList、 Cmd_Requ帧Control等，统一采用UDP协议进行传输。由于控制命令非常小，它的传送与接收也 没有放到专门为某个用户创建的服务子线程中，而是由一个“控制命令处理模块”对所有用户的命 令进行统一的处理，再通知相应的线程。 服务器只有在接收到客户的点播请求命令，并且还有线程资源的情况下，才会为此客户创建一 个服务子线程为其服务。 3媒体数据实时传输层 服务器收到客户的点播要求后，子线程会打开所点播的视频文件，进行压缩编码后，实时传输 给用户。 对于互联网这样基于包交换的信道，网络状况不稳定，丢包、不均匀延迟的情况时有发生。传 统的互联网应用对于延迟时间的要求相对较松，更需要保证的是其可靠性。因此传统的应用一般都 使用可靠的TCP传输协议实现传输。然而对于网络流媒体的传输，为了保证平滑的观看效果，要求更 少的延迟和更小的延迟波动。对于这种实时性的要求，目前流行的方案是用RTP协议作为流媒体传 输协议。 RTP ( real-time transport protocol)协议被定义为传输音频、视频、模拟数据等实时数据的传输 协议。最初的设计是为了数据传输的多播，但也可用于单播。与传统的注重高可靠性的数据传输层 协议相比，它更加侧重数据传输的实时性，提供包括时间载量标识、数据序列、时戳、传输控制的 服务。RTCP ( real-time transport control protocol)是设计成与RTP 一起使用的，进行流量控制和拥 塞控制的服务控制协议。它在RTP会话之间周期地发放一些RTCP包，用以实现传输监听服务质量 和交换会话用户信息等功能。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计 资料。服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合 使用，能以有效的反馈和最小的开销使传输效率最佳化，因此特别适合网络数据的实时传输。 虽然RTP协议很好地解决了UDP协议所带来的丢包和乱序的问题，但是它对关键的I帧的丢弃， 容易造成以I帧为预测基准的其他帧不能得到有效的恢复。有鉴于此，我们对其进行了改造，发送控 制框图如图2所示。 根据接收到的用户命令，查询视频数据库，得到用户所要点播的视频文件。假设其为AV1格式 的文件，首先要对AVI文件进行分解，转化为YUV12格式的纯视频信号，然后取出每一帧图像， 对其进行MPEG-4编码，编码框图如图3所示。编码过程中压缩率要受到客户端反馈的控制，以保 证平滑的视频播放效果。 313视频数据在MPEG—4编码后，将其按照I帧和P帧分类，分别进行传输。虽然都是按照RTP 协议传输，但是在传输I帧时，要求客户端对数据的接收