毕业设计（论文）-IP语音电话设计与实现.doc

毕业设计（论文）题 目 IP语音电话设计与实现 学 院 理学院 专 业 信息与计算科学 班 级 2010级 2班 学 生 学 号 指导教师 重庆交通大学2014年6月2014届信息与计算科学专业毕业设计（论文）摘 要随着Internet的迅速发展以及个人计算机处理能力的增强，软件实现方式的IP可视电话系统成为网络视频应用研究的一大热点。但是，目前的IP网还存在网络服务质量欠缺、网络带宽瓶颈、网络访问限制等问题，这使得IP可视电话系统的普及变得困难。针对以上问题，本文从视频流的压缩编码、传输与调度入手，研究具有高伸缩性、高质量、低成本的IP可视电话系统的设计与实现方法。首先，视频的编码传输是实现整个系统的基础。为了提高视频传输的实时性和效率，本文给出了一种Internet网上的基于MPEG-4视频压缩编码的视频流传输模型，保证了在低比特率及Internet网下能够提供良好的图像质量以及网络资源的有效利用。其次，根据MPEG-4视频流特点和网络的拥塞程度，本文给出了一种改进的适合MPEG-4视频传输区分服务的模型，弥补了传统的IP网络“尽力而为”传输方式的不足，保证了网络服务质量。然后，本文给出了一种新的穿越NAT的方法。通过SIP协议及TCP/IP协议实现了局域网与局域网、局域网与互联网、互联网与互联网之间的数据通信，从而解决了网络访问障碍问题。并且，服务器根据客户端之间的网络连接方式动态地决定采取单播或多播或P2P方案，减少了客户端与服务器间的通信量，从而减少了服务端的下行带宽，带宽瓶颈问题得以较好地解决。最后，本文给出了IP可视电话系统的一个具体实现及其性能测试。为分析该系统的性能，论文建立了一个客户端仿真模型，利用仿真程序对系统进行性能测试。测试结果表明，该系统能够在宽带网上提供适时的良好质量的视频服务。 关键词：流媒体，IP可视电话，QoS，MPEG-4，NAT，RTCP/RTPAbstractWith the rapid development of Internet and the improvement in the processing ability of PC, IP videophone system, one of the ways of software realization, has become a focus on the research of the network video application. However, for the moment, some problems still exist, such as service quality, bandwidth bottleneck, network access limits and so on, which increase the difficulty in making IP videophone system popular.Aimed at the problems mentioned above, starting with the video streams compression and coding, transportation and scheduling, this thesis works on the design and realization of the IP videophone system with good scalability, high quality and low costs.Firstly, with the target to improve the real-time and effectiveness of video transportation, the video compression and coding and transportation are the foundation of put the whole system into motion. The thesis presents one model of video stream transportation, which is based on the MPEG-4 video compression coding. This model ensures to provide pictures of high quality and make effective use of the Internet resources in low bit rate on the Internet.Secondly, according to the features of video stream and the congestion level of Internet, this thesis provides one improved model, fit for MPEG-4 video transportation DiffServ, which makes up the disadvantage of the traditional IP Internet transportation characterized by its “best-effort” and assures the Internet service quality.Thirdly, the thesis proposes a new method to traverse NAT. Through SIP and TCP/IP, the problem of access obstacles on Internet is solved by the communication between LAN and LAN, LAN and internet network, internet network and internet network. Whats more, the server decides if unicast or multicast or P2P will be used according to the Internet linking style among the clients, which reduces the amount of the communication between the client and servers output-bandwidth. Thus, the problem of bandwidth bottleneck is well solved.Lastly, this thesis provides an approach to the actual realization and performance testing of the IP videophone system. To analyze its performance, a simulation model on the clients side is created and simulation program is employed to test the systems performance. Results proved that the system is able to, when needed, supply video service of good quality on broadband Internet. Keywords：Streaming Media, IP videophone system conferencing, QoS, MPEG-4, NAT, RTCP/RTP目 录第1章 绪 论11.1 课题的研究背景11.2 国内外研究现状11.3 论文的组织结构2第2章 端到端的MPEG-4视频流传输框架研究32.1 引言32.2 MPEG-4视频传输框架32.2.1 概述32.2.2 RTP/RTCP协议42.2.3 反馈控制52.2.4 源编码率控制62.2.5 MPEG-4比特流打包72.2.6 错误控制72.3 端到端反馈控制协议82.4 一个打包算法92.5 仿真结果122.5.1 仿真设置122.5.2 对等网络配置下的性能122.6 本章小结17第3章 MPEG-4视频流传输QoS的研究183.1 引言183.2 基于网络的QoS解决方案183.2.1 DiffServ体系193.2.2 MPEG-4视频流传输区分服务（DiffServ）213.3 DiffServ网络模型223.4 仿真实验及结果263.5 本章小结30第4章 流数据跨NAT传输技术及调度方案31III4.1 引言314.2 相关技术324.2.1 NAT基本原理324.2.2 网络互连及NAT类型334.2.3 SIP协议334.3 穿越NAT的方法344.3.1 局域网间及其与Internet网间通信354.3.2 一个通用的解决方案384.3.3 NAT中动态地址映射保存问题434.4 流调度方案434.4.1 调度方案434.4.2 一个实例444.5 本章小结45第5章 系统的设计实现及性能分析475.1 系统实现分析475.1.1 几个关键问题475.1.2 采用的协议495.2 系统的设计与实现495.2.1 系统结构495.2.2 主控模块505.2.3 语音视频管理模块525.2.4 语音视频压缩解压模块545.3 系统测试565.3.1 系统开始运行界面：565.3.2 呼叫界面565.3.3 接收呼叫请求界面575.3.4 会话建立后的界面575.4 本章小结57第6章 总结及其展望595.1 全文总结595.2 展望59参考文献61致 谢63V第1章 绪 论1.1 课题的研究背景随着网络技术和数字通信技术的飞速发展，Intenet越来越影响着人们的生活，也带动了以IP为基础的各种应用的迅猛发展。随着网络带宽和计算机处理能力的不断提高，在宽带网上实现高速多媒体通信己成为可能，一些传统的数据通信业务包括语音和视频等开始转向IP。1995年2月以色列VocalTec公司研制出可以通过Intenet网打长途电话的软件产品“IntenetPhone”。用户只要在多媒体PC机上安装该软件，就可以通过Intenet网和任何地方安装同样软件的联机用户进行通话。这种在Intemct上实现电话业务被称为Intenet电话，应该说是IP电话的雏形。IP电话的出现，以其低廉的通话费用及其诱人的市场前景吸引了众多公司包括服务提供商和电信运营商的眼球。许多公司纷纷投资对其进行研究开发，从而使IP电话技术得到迅速发展。起初由于技术的不成熟，电话在发明初期只能进行语音通信，但是人们对视频通信的期望从未减退过，在语音通话的同时还能看到对方的图像会使通话过程变得更有亲切感1，因为视频往往能传达语言无法表达的信息。正因为如此，人们都愿意使用可视电话，或者远距离参加视频会议。但到目前为止类似于可视电话以及视频会议的视频业务仍没有获得广泛应用。这些视频业务没有走进寻常百姓家的主要原因是受到通信条件的制约，特别是传输资源紧缺和价格昂贵，接入技术单一、落后2。随着网络建设的日益完善，网络环境的不断提升。使计算机与电信之间的界限也被逐渐打破。因此，基于纯软件的网络电话也就在这种融合中诞生了，随着技术的迅速发展，软件实现方式的IP电话技术已成为电信网的主流技术。软件实现方式的IP电话技术是一项涉及计算机网络、电信网络、信令协议、数字信号处理等多个领域的综合性技术，是下一代网络应用的热点。1.2 国内外研究现状随着IP技术框架中汇聚网络研究的发展，数据网络通信已经融入传统的话音业务领域。从现实情况来看，在电信数据业务中，IP业务已占95%以上，可以说数据承载网业务已基本IP化。可以看出，目前电信网中的业务除了传统电话业务外都是IP业务，而电话业务中的长途电话70%已是IP电话。IP网络技术的优势是显而易见的，语音、传真、视频和数据等业务可以在IP网络上便宜的传送，如统一消息、虚拟电话、虚拟语音/传真邮箱、查号业务、Internet呼叫中心、Internet呼叫管理、电视会议、电子商务、传真存储转发和各种信息的存储转发等。但是，国内在桌面IP可视电话系统尤其是纯软件实现方式研制方面一直比较落后，这与我国软件的总体水平不高有关系。少数几个面世的系统，大多采用面向连接的技术，并且系统没有得到普及和推广。另外，国内也有不少公司企业推出自己的桌面IP可视电话系统，其解决方案适合采用分组交换技术的网络环境，实现IP电话系统的基础是H.323协议，仍然是利用MCU和各个终端连接。1.3 论文的组织结构本论文由5章构成。第1章即本章是全文的绪论部分，给出了课题研究背景、国内外研究现状。第2章主要介绍了一种基于MPEG-4与Internet网络环境下的视频流传输框架。第3章主要介绍了网络服务质量技术。介绍了MPEG-4视频特点以及网络的拥塞技术，给出了一种适合MPEG-4视频传输的区分服务模型。第4章主要介绍了视频流数据跨越NAT网关传输的技术。首先介绍了SIP与RTP/RTCP协议，然后介绍了如何突破NAT限制来解决网络访问障碍的技术。第5章主要介绍了系统的实现及性能测试。首先分析了系统实现的几个关键问题，然后介绍了系统的实现模型，最后对系统在局域网环境下进行了测试。最后，总结了本文的工作并提出了下一步的设想。第2章 端到端的MPEG-4视频流传输框架研究2.1 引言随着Internet网的成功以及多媒体通讯时代的到来，MPEG-43国际标准已成为研究热点，基于MPEG-4的应用在不久的将来势必会成为网络多媒体的应用热点。由于MPEG-4采用了基于对象的编码和基于模型的编码等第二代编码技术从而使之具有灵活性与高效性，除了传统的存储与视频传输外，它能够提供交互的基于内容的视频服务。Internet视频传输不同于其它数据类型的传输，Internet视频应用对延迟与丢失有独特的要求。此外，在Internet网上的通信量负载是随着时间急剧变化的，这影响了视频的传输。因此，在Internet网上设计一个有效的既能够充分利用资源又能够为用户提供最佳的感知服务质量的视频传输框架将是一个挑战。本章首先概述了一个视频传输框架的主要部分，包括源端速率自适应、打包、端到端反馈控制及错误控制。由于当前的Internet仅提供“尽力而为”型的服务，因此，在端系统(发送端与接收端)之间实现反馈控制以便发送端能够调整它的传输速率是有必要的。为了在网络上传输，需要对MPEG-4视频源数据进行打包。因此，为了在效率与图像质量方面达到良好的性能，适当的打包算法是必要的。最后，为了减少包在传输过程中由于包丢失而导致图像质量降低的影响，采用相应的错误控制方案也是必要的。最后对MPEG-4视频传输框架的性能作了仿真测试。2.2 MPEG-4视频传输框架在本章中，我们概述了在Internet之上传输视频的关键组成部分。本章组织如下。在2.2.1节，综述了本章的端到端系统。从2.2.2节至2.2.5节简要描述了端到端系统的每一个组成部分。2.2.1 概述图2-1说明了一个在Internet网上传输MPEG-4视频的框架。给出的框架既适合预先压缩的视频又适合实况播放的视频。如果视频源是预先压缩的视频，可以由反馈控制协议通过动态的速率调整或选择性地丢弃帧4来使速率与流比特率相匹配。如果视频源是一个实况播放的视频，本章就使用2.4节所描述的MPEG-4速率自适应算法来控制编码器的输出率。图2-1 一种MPEG-4视频传输模型在发送端，实况播放的视频的原始比特流经过一个自适应的MPEG-4编码器编码。在这个阶段之后，已压缩的视频比特流首先在同步层(SL)被打成包，然后经过RTP/UDP/IP层进入Internet网络。包可能在一个路由器/交换机(由于阻塞)或目的地(由于超时延迟)处被丢弃。成功被传递到目的地的包在MPEG-4解码器处被解码前首先按反方向经过RTP/UDP/IP层。在传输框架中，在接收端有一个QoS监测器，它根据到达包的行为(如包丢失与延迟)来推断网络阻塞状况。这样的信息在反馈控制协议中将被用到，并被发送回源端。基于这样的反馈信息，发送端估计可用网络带宽并控制MPEG-4编码器的输出速率。2.2.2 RTP/RTCP协议由于TCP的重传机制引入了延迟，而MPEG-4视频应用对于延迟有严格的要求，所以一般不用TCP作为视频传输的协议，而采取UDP作为MPEG-4视频流的传输协议。另外，由于UDP不提供包传输保证，接收方需要依赖于上层(如RTP/RTCP)来检测包的丢失。RTP5是一个Internet标准协议，被设计用来提供端到端的传输功能以支持实时应用。RTCP是一个传输控制协议，一般和RTP协议结合使用。RTCP被设计来为一个RTP会话中的参与者提供QoS反馈。RTP不提供QoS或可靠传输，但提供一些基本的几乎所有实时应用的公共功能。一个RTP支持的关键的特征就是包序列号，它能够被用来在接收方检测包的丢失。RTCP通过在源端与目的端分别使用发送方报告(SR)与接收方报告(RR)来提供QoS反馈。特别地，RTCP保持总的控制包占总的会话带宽的5%。在这些控制包中，25%被分配给发送方报告，而75%被分配给接收方报告。为了避免控制包饿死，在发送方或者接收方每5秒以内至少发送一个控制包。图2-2说明了RTP/UDP/IP层的实现模型。该模型是实现基于速率的反馈控制协议与错误掩盖机制的一个关键部分。从发送部分来看，MPEG-4编码器生成一个打包流，它被转变成RTP包。另一方面，来自反馈控制协议(发送端)的信息被传递到RTCP发生器。随后RTCP与RTP包下传到UDP/IP层用于在Internet网上传输。在接收部分，已接收到的IP包首先被UDP/IP层拆包，然后被过滤器以及分发器分发到RTP与RTCP分析器。RTP包在被解码前被RTP分析器拆包并被放入一个缓冲器用于丢失检测目的。当检测到包丢失时，消息将被发送到错误掩盖部分。另一方面，RTCP分析器拆分RTCP包并发送反馈信息到反馈控制协议部分。2.2.3 反馈控制Internet视频应用具有独特的和其它数据类型有区别的延迟与丢失要求。另一方面，当前的Internet并不广泛支持任何的带预留机制或其它的QoS保证。此外，可用带宽不仅是不可知的，而且是随时间不断变化的。因此，对于MPEG-4视频源必须要有一个机制来感知网络条件变化以便它能够用适当的输出速率来编码视频。理想地，我们愿在网络阻塞点实现阻塞提示以及反馈，如，在一个交换机/路由器的链路瓶颈处。在这样的一个环境下，在交换机处设计强大的速率计算算法并将精确的可用带宽信息6传达给源端是可能的。不幸地，在当前的Internet环境下，IP交换机/路由器并不积极参与反馈控制。所有的流控制与错误恢复功能留给了端系统与上层应用。在这样的一个环境中，我们仅能够把Internet当作一个黑盒子来对待，包的丢失与延迟不在我们的控制之中。反馈控制算法被单独地设计在端系统，在IP交换机/路由器上没有任何附加的要求。在本框架中，让MPEG-4视频源逐渐地增加它的传输速率以探测可用带宽。这样的一个速率增加将首先让源速率达到可用的网络带宽，然后源速率将会超过可用网络带宽并且陷入阻塞区。接收方通过在接收到的包中的包丢失/延迟来检测阻塞。接收方发送反馈RTCP包给源端来通知它关于阻塞的状况。一旦源端接收到这样的一个反馈，它就降低它的传输速率。反馈控制的挑战在于这样一个算法的合理设计：源端能够跟上网络带宽的变化并且网络被有效利用。在第2.3节，给出了采用包丢失作为阻塞信号以及使用RTCP控制包来传递阻塞信息的反馈控制算法的细节。图2-2 RTP/UDP/IP模块2.2.4 源编码率控制源编码速率控制算法的目标就是在一个给定的编码速率条件下达到最好的感知质量。这样的自适应编码可以通过编码器的压缩比或者视频帧率单独或同时变更来完成。传统的视频编码器一般依赖于变更编码器的压缩比来实现速率自适应的。这些编码方案使用固定帧率执行编码。在这些编码器中，帧速率的变更经常不被采用，因为甚至一个微小的帧率的降低都能够充分降低接收方的感知质量，尤其是在动态场景变化期间。另一方面，MPEG-4视频编码器将每个单独的视频对象划分成VOP并对每个VOP独立进行编码。这种视频对象的分离给我们提供了执行自适应编码的更大的灵活性。特别地，除了对每个VOP压缩比的变更外，我们还可以在视频对象之中动态地调整目标比特率的发送。在2.4节，将给出一个MPEG-4源编码速率控制算法。该算法能够达到期望的输出率以及很好的感知质量。2.2.5 MPEG-4比特流打包因为MPEG-4视频流为了在网络上传输不得不需要转换成包，所以一个打包算法是很有必要的。由于MPEG-4的VOP特性，需要仔细地设计一个适合Internet传输的MPEG-4打包算法，因为H.261/263与MPEG-1/2不能够在这里直接被应用。本章在2-5节将给出一个同步层的既能达到高效性又能达到健壮性的MPEG-4视频打包算法。2.2.6 错误控制Internet包丢失的主要原因在于路由器处的阻塞。此外，网络的多路径路由，包可能延迟到达或者接收到的包失序。由于接收方的适时性要求，如果延迟超过了一个最大的阀值，那么这样延迟到达的视频包可能被认为是丢失的包。尽管MPEG-4视频流能够容忍一些丢失，但它在接收端降低了感知质量。因此，错误控制与恢复机制必须达到能够维持一个可接受的感知质量的程度。早先的关于错误控制的工作主要集中在两方面，如前向纠错(FEC)与重传79。因为FEC需要占用较大的带宽，所以它不可能适合于甚低速率的MPEG-4视频。我们也不赞成基于重传的错误控制方案，因为基于重传的视频传输方案会进一步恶化网络阻塞并引起网络崩溃。另一个处理传输中的错误与丢失的方法是错误恢复编码。错误恢复机制包括重同步标记、数据分离、数据恢复(如反向可变长度编码，RVLC)以及错误掩盖1014。然而，重同步标记、数据分离以及数据恢复面向的是像无线信道以及并不适合于Internet的易发生错误的环境。对于在Internet上传输视频，在接收端的可变长度编码比特流中，一个包的边界提供了一个同步点。由于一个包的丢失也许引起所有的运动数据以及与它相关联的形状/纹理数据的丢失，像重同步标记、数据分离以及数据恢复的机制也许对于Internet视频应用没有什么有益处。另一方面，文献13讨论的大部分错误掩盖技术仅适合于ATM或无线环境，并且需要实质的额外的计算复杂性，这在解码静态图像情况下是可以容忍的，但在解码实时视频时却是无法容忍与接受的。因此，本文仅考虑一种简单的适合于Internet视频应用的错误掩盖方案。基于以上的考虑，本文采用一种简单的如下的错误控制方案。包的丢失由接收端的QoS监测器通过检查RTP包序列号来检测(见图2-1)。在本章的实现中，如果一个包延迟超过了位于它后面的第四个包，我们就认为这个包丢失了(尽管它可能在将来某个时间到达)。在这里，根据最大的重放延迟，选择第四个包作为阀值。最大重放延迟能够由用户根据应用的需求来指定。本章的错误控制算法由两部分组成。在解码器端，当包丢失被检测到时，通过简单地重建VOP数据来恢复相应的丢失包的图像区域。在编码器端，编码器通过周期性地编码帧内视频对象平面(intra-VOP)来控制错误的传播。2.3 端到端反馈控制协议与2.2.3节讨论的一样，在当前的Internet网中的交换机/路由器不提供直接的关于可用网络带宽的速率反馈信息。我们仅能够在终端系统间接地通过延迟(如往返时间，RTT)或者包丢失率来估计网络可用带宽。Dabbous说明了用基于RTT反馈的连接吞吐量要低于像使用基于丢失反馈的TCP这样连接的吞吐量15。因此，在接收端选择采用包丢失率测量作为方案的反馈信息。和RTP/RTCP标准一致，本文让源端周期性地为每Ns个RTP包发送一个RTCP控制包。接收端一旦接收到Nr个包就立即或至少每5秒发送一个反馈RTCP控制包给源端。返回的RTCP包包括包丢失率Ploss，接收端在自上一个反馈RTCP包以来的Nr个包时间间隔期间观察丢失率。编码器一旦接收到一个由好变坏的RTCP包就进行速率控制。因此，源端的连续速率控制的间隔大约和连续的由好变坏的RTCP包的间隔相等。下面是发送端与接收端的反馈控制协议，其中，IR、MR以及PR分别是发送端初始速率、最小速率以及最高速率。AIR是加法增长速率、乘法减少因子以及包丢失率阀值。算法1 (反馈控制协议)，包括发送端与接收端。发送端：(1) 发送端以输出速率r：= IR开始发送，该发送速率大于或等它的最小速率MR；每个RTP数据包包含一个包序列号。(2) 每传送Ns个RTP数据包，发送端就向前发送一个RTCP控制包。(3) 一旦接收到带有从接收端来的包丢失率Ploss的回返的RTCP包，在源端的输出率r根据以下规则进行调整：if (Ploss Pthreshold )r：= min(r + AIR)，PR;elser：= max(a r)，MR接收端：(1) 接收端获悉达到包RTP头的序列号。(2) 一旦接收到Nr个包或至多5 s，接收端就发送一个在时间间隔之间观测到包含丢失率Ploss的反馈RTCP包给源端。在一个控制活动期间，反馈控制算法(算法1)通过调整MPEG-4编码器的输出速率来努力维持包丢失率在阀值Pthreshold以下。在一般方案中，当在一个反馈RTCP包显示出没有阻塞的情况时将采用乘法增加速率调整的方法16，与该方案不同的是，本文在算法1中采用加法增加，它是一个保守的适合可用带宽的速率增加的方法。 经验表明，在一个大型网络中，乘法增加方法常常比保守的速率调整方法带来更大的源速率摆动以及更多包的丢失。另一方面，本文在算法1中采用乘法减少方法，在源端将会发现Ploss大于返回的RTCP包中的阀值。我们发现在源端这样快速的速率降低必然缩短阻塞时间以及降低包的丢失率。2.4 一个打包算法压缩的视频流在包交换的IP网络传输以前，它必须先被打成包。在发送端，首先通过使用编码算法来压缩原始视频，然后，压缩的MPEG-4视频流在传输到TransMux层之前，除了分片与随机访问信息外，在同步层与时序及同步信息一起被打成包。到目前为止，对于MPEG-4视频基本流在同步层的打包方法还没有被充分地论述到17。一个适当的在该层的打包算法对于MPEG-4视频在Internet上进行有效的、稳定的传输来说是很有必要的。Le Leannec与Guillemot18对于MPEG-4视频流使用一个固定的包尺寸。这种打包方案是非常简单的，但一个MB也许会被分成两个包，导致这两个包相互间有依赖性。有人提议采用一个MB作为一个包。在这样的方案下， MB是最小单元。因此，一个包的丢失仅仅破坏一个MB，这增强了视频的错误恢复能力。由于这个原因，该打包方案被IETF推荐使用。为了增加效率，也有人提议采用一个GOB作为一个包。在这种方案下，GOB是最小单元。因此，包丢失仅破坏一个GOB，增强了视频的错误恢复能力。因此，这种打包算法也被IETF所推荐使用。与上述研究工作不同的是，本文利用了MPEG-4中的VOP特性并设计了一个同步层的打包算法，该算法提供了在Internet上传输视频流的有效性与稳定性。其算法的有效性与稳定性已通过仿真实验得到证明。显而易见，大包的使用将减少包与头信息结构(共50 bytes=3 bytes的SL头+3 bytes流复用头+16 bytes的RTP头+8 bytes的UDP头+20 bytes的IP头)总的生成的数量。另一方面，包的大小不能大于最大传输单元(MTU)，MTU被定义为从源端到目的端所有的通过链路的MTU中的最小值。这是因为任何大于MTU的包将会导致IP分片，这会为每一个分片包带来额外的包头。令事情更糟的是，一个分片包的丢失将会破坏其它的源于相同原始包的分片包。而且，对于MPEG-4视频，我们不建议将包含两个视频对象平面交叉信息的数据进行打包，因为这样包的丢失将会破坏两个视频对象平面。由于这些考虑，本文选择当前VOP大小与MTU的最小值作为包的大小。在当MTU信息不可用的情况下，使用默认的MTU值(如576 bytes)。当一个VOP太大以至于不适合一个单个包时，它就有必要被拆分成多个段并使用多个包。本文既努力将一个给定的MPEG-4比特流产生的包的数量减少到最小，又努力减少相邻包之间的依赖性。将包数量减少到最小化的目的就是将信息头减少到最小化，而将相邻包之间的依赖性减少到最小的目的就是达到稳定性。如果MPEG-4视频对象平面头信息被拷贝进每个包，那么包之间的这种依赖性就能够被去掉。由于一个MB的大小总是小于MTU，所以一个包可以由至少一个MB组成。本文的打包策略如下。如果一个完全的视频对象平面适合一个包，那么就将这样的视频对象平面打成一个单独的包。否则，我们就努力将尽可能多的MB打进一个包(对于相同的VOP将其头信息拷贝进每个包中)而不与下一个VOP相交叉，即使对于当前VOP的最后包中有可用空间。也就是，来自连续的视频对象平面的MB决不被放进相同包中。本文给出的打包方法既达到了对于低比特率编码很有必要的效率，又达到了避免包丢失的健壮性(由于包中的VOP之间严格的边界以及包中相同VOP头信息的拷贝)。首先描述本文打包算法的功能及用到的参数。(1) BitCount是一个记录当前打包过程中读取的比特数的计数器。(2) MaxPL或最大有效载荷长度(bits)，等于(MTU-50 bytes) 8。(3) VOP_start_code是一个从VOP一开始就预先定义的代码并被看作是两个连续VOP之间的边界。算法2 (一个打包算法)：while (there is encoded data to be packetized)search for next VOP_start_code and BitCountcounts the number of bits of the video stream;if (next VOP_start_code is found) and (BitCount-length of VOP_start_code MaxPL)/*Packetize by VOP boundary*/packetize the bits before next VOP_start_code;else if (BitCount-length of VOP_start_code MaxPL)/*Packetize by MBs.*/Packetize as many MBs as possible without exceeding MaxPL and without Crossing into next VOP;else /*Next VOP_start_code is not found, i.e.,end of video.*/Packetize the remaining data.算法2开始检查是否存在打包的已编码的数据。首先，测试正被读取的VOP是否能被包含进一个长度不大于MaxPL的包中。如果是，被读取的数据将被传递给下一阶段，也就是RTP打包包装器。否则，算法转到MB层，即打包是在MB的边界上被处理的。如果VOP_start_code没有被找到并且读取的比特数小于MaxPL，这意味着到达了视频流的末端，于是打包剩余的数据。由于一个VOP大于一个MB或一个GOB，算法2达到了比较高的效率。算法2也去掉了包之间的依赖性，解决了Le Leannec与Guillemot方案遗留下来的问题。2.5 仿真结果在这节，给出了结构与算法在网络仿真器上的实现以及MPEG-4视频在Internet网上的传输的仿真研究。本节给出的结构与算法能够实现：(1) 在低比特速率与对等网条件下传输MPEG-4视频流并达到良好的感知图像质量。(2) 适应可用网络带宽并有效利用它。2.5.1 仿真设置本文使用的网络配置是对等网。在视频源终端，对于MPEG-4视频编码器，使用标准的QCIF格式的原始视频序列“Akiyo”。编码后的比特流在被发送到网络之前，除了RTP/UDP/IP协议外，也用本文给出的打包算法(算法2)对它进行打包。包有可能由于网络阻塞被丢失。对于到达的包，接收端从比特流中取出包的内容给MPEG-4解码器。对于一个丢失的包，与丢失包相关联的VOP将被丢弃掉并且前一个VOP将被拷贝过来。为了控制错误，源编码器每100帧就编码一个Intra-VOP。表2-1列出了本章仿真用到的参数。本文用576 bytes作为MTU大小。因此，最大有效载荷长度MaxPL是526 bytes(576 bytes减去信息头的50 bytes)。2.5.2 对等网络配置下的性能本文采用如图2-3所示的标准对等网基准网络配置作为Internet环境(图2-1)。因为在发送端与接收端之间仅有一个瓶颈链路(也就是在所有通过的链路之中的具有最小带宽的那个)，所以重点在这种简单的网络结构下获得在Internet网内的一个传输路径的基本特性。此外也强调，在Internet网上，尽管多路径以及因此引起达到包的失序的问题，本文用简单对等网络结构实验所得结果的有效性与一般性也不会大打折衷，因为本文给出的结构与算法是在终端系统(发送端与接收端)设计并实现的。因此，一个由于多路径路由的原因而在阀值之后抵达的包能够在目的端被看作一个丢失的包，并且本文给出的结构与算法在这种情况下保持不变，通用性与适应性强。表2-1 仿真参数端系统MPEG-4MaxPL4208 bitsIR10 KbpsAIR0.5 KbpsPR200 KbpsMR5 Kbps0.95Ns79Nr25Pthreshold5%Buffer Size1 MbytesTCPMean Packet Processing Delay300 sPacket Processing Delay Variation10 sPacket Size576 bytesMaximum Receiver Window Size64K bytesDefault Timeout500 msTimer Granularity500 msTCP VersionReno交换机Buffer Size10 KbytesPacket Processing Delay4 sBuffer ManagenmentTail Dropping链路端系统到交换机Link Speed10 MbpsDistance1 km交换机到交换机Distance1000 km本节组织如下：首先说明了一个在不同网络带宽下的MPEG-4视频的性能，然后，让MPEG-4与竞争TCP连接相结合使用并说明它的性能。(1) 在各种网络带宽下的MPEG-4 视频。在这个仿真中，我们在对等网络配置下仅激活一个MPEG-4视频源。从图中可看出，在SW1与SW2之间的链路容量从区间0, 150的15 Kbits/s变化到区间150, 300时的50 Kbits/s，然后在300 s之后又降到25 Kbits(见图2-4)。图2-3 一个对等网络图2-4 对等网环境下测试结果图2-4(a)说明了在450 s的仿真运行期间的网络链路带宽与源速率行为。从图中可发现源端能够调节它的输出率与变化的可用带宽保持一致。图2-4 (b)说明了在同一个仿真运行时的链路利用与包丢失率，这与图2-4 (a)说明的是一致的。在源速率(图2-4 (a)与网络利用(图2-4 (b)中的摆动是由于链路延迟的传播以及反馈控制算法的二元本性所致。源端执行加法的速率增加直到它到达了可用的链路带宽。在那之后它将会超过可用带宽并导致阻塞与包丢失。在接收端检测到包丢失并将这样的信息传递给源端，一接收到这样的反馈，源端就减少它的速率。尽管有摆动，瓶颈链路的平均利用率超过了80%，这是在一个广范围的Internet上反馈控制的一个相当好的结果。此外，还发现平均包丢失率仅为0.35%，这就证明了给出的反馈控制算法的有效性。在原始视频序列与接收视频序列之间的差别的一个量度标准就是峰值信噪比(PSNR)。图2-5说明了在接收端在如图2-4所示的相同的仿真运行下的MPEG-4视频的Y值的PSNR。图2-5通过以下步骤得到。首先，视频序列在目的端被重建，在目的端，错误掩盖机制(即拷贝前一个VOP)被用来掩盖包丢失的影响，然后，对每个重建帧计算PSNR。图2-5 对等网接收端VOs的PSNR(2) 与竞争TCP连接相结合。在对等网络中(见图2-3)设置SW1与SW2之间的链路容量为常量100 Kbits/s。 除了一个MPEG-4视频源外，我们激活10个TCP连接与MPEG-4视频共享链路带宽。图2-6(a)说明了在仿真运行450 s的期间源速率的行为。从图中可以发现源端能够调整源速率与其它的TCP连接动态地共享网络带宽。由于TCP窗口的调节时间间隔远小于MPEG-4编码器速率的调整，TCP连接能够比MPEG-4更快地调用任何剩余的网络带宽并充分地利用全部的网络带宽。图2-6 (b)说明了在Link12处的网络链路利用，该处的利用率在绝大部分时间是100%。图2-7说明了同一个仿真运行下的在接收端的MPEG-4视频的Y的峰值信噪比(PSNR)。在图2-7中的平均包丢失率是0.95%，并且，发现接收端的感知图像质量很好。图 2-6 源速率以及网络利用与包丢失率图2-7 对等网下接收端VOs的PSNR2.6 本章小结MPEG-4视频标准通过使用基于VO的编码而具有提供基于内容的视频服务。MPEG-4视频是许多多媒体应用的一个重要部分。另一方面，由于当前Internet缺乏QoS支持并且可用带宽、延迟及丢失随时间而变化，要达到满意的MPEG-4视频质量传输仍有许多值得去挑战、解决的问题。给出了一个Internet上的传输MPEG-4视频的端到端框架。仿真结果表明，给出的MPEG-4传输框架与算法能够提供良好的感知质量，并有效地利用了网络资源。第3章 MPEG-4视频流传输QoS的研究3.1 引言近年来，随着高速计算机网络、数字视频压缩技术的快速发展，促进了网络多媒体尤其是流媒体技术在Internet上的应用。这些应用包括基于IP的视频电话、视频点播、视频会议、视频聊天以及视频教学等。然而，这些多媒体技术在Internet上的应用质量与效果却无法得到保证19。一方面，多媒体数据流占用带宽高，数据流适时性强，对网络带宽、传输延迟以及分组丢失有着严格的要求；另一方面，当前的Internet的单一等级尽力而为服务无法提供QoS保证，使得Internet上视频流成为具有挑战性的一个课题。目前有两种解决思路，一种是以网络为中心，提高网络带宽，提供QoS保证，如使用RSVP20,21(资源预留)或DiffServ22,23(区分服务)等。另外一种是以终端系统为中心，对于改善Internet多媒体应用性能更为有效。关于以终端系统为中心的解决方案，已在本文第二章作了讨论，本章主要讨论基于MPEG-4视频流传输的DiffServ的网络解决方案。3.2 基于网络的QoS解决方案当前Internet为单一等级尽力而为服务，无法提供QoS保证，为了提高网络服务质量，必须对带宽进行有效管理，QoS就是针对这种管理策略的协议。QoS本身并不增加带宽，只是对带宽进行有效的管理。现在的QoS主要分为3种：(1) RSVP 根据申请QoS请求进行资源分配，根据带宽资源进行管理。RSVP提供了这一种管理机制，但在当前Internet的永久虚电路PVC服务运营模式下，扩展性差，难于在大型IP骨干网上实现，RSVP几乎不具备可行性。(2) DiffServ 近几年IETF(Internet Engineering Task Force)在QoS领域做了很多新的尝试，区分服务也应运而生，导致产生了DiffServ体系协议结构。采用DiffServ体系作为大型IP骨干网的技术，这是近几年来IP QoS领域中重点研究和开发的热点问题。DiffServ的基本思想就是给业务分级，业务的分级基于每个数据包的不同标识。同一级别的业务在该网络域中会被聚合统一传送，保证相应的延时、抖动、带宽等服务质量参数。DiffServ并不提供从发送端到接收端的端到端服务质量保证，而是在域(Domain)的范围内保证与业务分类相对应的服务质量，每个域之间对于不同类别业务的服务质量都应有一定的约定。DiffSe