IP网上视频通信的控制机制

李晓东 裘正定

解决这一问题提出了两种方案：

　　①在尽力而为的基础上增加其他提供不同程度的行为保证的服务。这需要在网络中实现具体的资源分配和预留机制，这一机制在因特网中还没有被广泛地使用；

　　②根据网络提供的服务调整应用的行为来实现相应的自适应操作。这种方法正被应用在现有的网络中。而且，即使在有显式的资源分配和预留的网络中，这样的方法仍旧具有实用价值。例如，自适应可以被用在很难对资源提前做出精确估计的情况中。而且，资源预留的代价较大，通常对较重要的数据采用预留的方式通信，而对于其余数据采用自适应的方法处理。

　　对于视频传输来说，重要的信道特性主要是端到端时延、可用带宽和包丢失率。从高效的端到端时延控制机制来考虑，应该采用更为细致的路由器内数据包排队方式，而不是传统的先入先出机制。同时，基于流的IP交换机制也是解决这一问题的重要方法之一。在端系统中主要采用缓冲调整的方式来解决时延抖动。对于可用带宽和包丢失的处理，现在主要有速率控制和差错控制两种机制：

　　①速率控制机制试图使一个视频连接的需求与整个连接链路的可用带宽相匹配。这样可以同时使网络拥塞最小和包丢失率最小。速率控制机制可以是基于源端的，也可以是基于目的端的。在基于源端的控制机制中，视频源端收集反馈信息，进行控制计算并采取相应的控制动作。这种方法在因特网中被率先采用。然而，这种基于源端的机制在异构网络中的运行情况并不是很好。基于目的端的控制机制则主要根据所接收的视频流的状况向上层反映相应的统计信息，实时调整缓冲及播放内容，并力图使节奏均匀。这种机制使用较少；

一、速率控制机制

　　速率控制机制在因特网中已被非实时应用广泛采用。最为人们熟知的例子是在TCP中的基于源端的控制机制。TCP通过预测网络拥塞状况来调整源端发送窗口的大小。CATV网络则采用基于本地缓冲应用情况的源端速率控制机制。

　　这些机制都是基于网络状态的信息反馈来调整相应的音频视频编码器的输出速率。只不过CATV网是基于本地状况的反馈而其他网络是基于整个网络状况的反馈。这样看起来，通常可以使用设计CATV网络时所使用的相同的控制机制。但事实上，为因特网设计同样效率的机制比较困难，这主要是因为：

　　①信道参数是时变的，这些变化是由于网络上存在的其他通信源的特征和需求与视频源有差异；

　　②所考虑的信道事实上是一个多播树，而这个多播树的组成可能很复杂，也许它包含着带宽、时延和包丢失特征不同的异构信道。

　　下面将研究在这种情况下基于源端的速率控制机制应怎样实现。尤其是要考虑一下对于视频应用来说速率调整如何实现；网络状况怎样被表达；反馈信息如何提供以及编码是如何根据信息来调整带宽需求的。

　　1.速率调整

　　这里主要考虑基于块的变换编码的情况，如Motion-JPEG，MPEG，H.261和H.263。

　　很明显，这类编码器的许多参数都可用来调整输出码流的速率。例如，降低视频的采样频率可以降低码流速率；增加视频的量化步长同样可以减少码流的单位时间比特量；提高运动检测的门限减少了自上一帧以来被认定为变化块的数目，这样也减少了编码每个图像的字节数，从而使输出的码流速率降低。

　　2.反馈信息的收集

——编码器采用RTP，UDP和IP多播方式发送视频信息。视频数据通过RTP打包传送，一个RTP数据包包含12字节的头，继而是载荷，即视频信息。视频帧组织是与编码相关的，在H.261，H.263中都有相应的规定。反馈信息通过RTCP包传送，RTCP包中包含有接收者报告包（RR）和发送者报告包（SR），这取决于发送该RTCP包的端系统是否在接收数据的同时也发送视频信息。报告包通过多播方式周期性地被发送至同样的多播组，即报告包既被送至源端也被送至多播组中的所有其他目的端。

　　报告包中包含有目的端得到的视频质量信息，具体包括接收到的最高序列号、包丢失数量、包到达抖动的估算法以及时戳(Timestamp）信息。

　　3.速率控制算法

　　源端在接收来自所有目的端的报告包之后，可以使用报告包中的信息来估计媒体流在网络中的拥塞状况以及在目的端的视频质量。

　　控制算法可以计算最大输出速率（max_rate），这主要参考TCP中使用的线性递增啃数递减算法。即max_rate可以以指数递减因子DECR来递减，并在无拥塞时以固定递增速率INC来递增。同时，整个算法应确保输出速率在一定范围（MIN_RATE，MAX_RATE]之间。

　　那么，如何判断拥塞的发生呢？事实上，没有一个很好的答案来回答这个问题。一个简单的选择是只使用报告包中的丢失信息来进行拥塞的指示。不采用抖动信息是因为没有找到一个好的原则来区分大的抖动和拥塞。

　　这里使用拥塞（Congestion）来表达报告包的丢失率超过了某个门限high_loss，用无拥塞（NoCongestion）来表示丢失率低于另一个门限low_loss，high_loss与low_loss的确定与特定应用。编码方式和具体网络有关，所以应通过反复实践获得。

二、差错控制机制

　　对于在包交换网络中的视频信号传输，包的丢失必定是影响视频效果的重要因素，而在源端采用的编码方法的影响也是相当大的。如对于H.263，H.261或MPEG中的编码方法，一个包的丢失可能会造成大量帧的质量下降，直到下一个帧内编码的帧被正确接收为止。然而，在一个有一定程度拥塞的或低速的网络当中，接收到两个帧内编码的帧的时间间隔也许会相当长。于是，人们提出了三种方法来解决这一问题：

　　①减少帧内编码的间隔，极端情况是一帧的间隔。在Motion-MPEG中采用这个方法后，带宽的需求随之明显增大；

　　②仅对那些变化量超过某一门限的块进行编码和传输；

　　③同时使用帧内编码和帧间编码，而且对于帧内编码的问隔根据网络状况动态地进行调整。

　　以上方法是通过调整帧内编码和帧问编码的帧的混合程度来使包丢失对视频效果的影响最小化。还可以使用简单的包丢失恢复技术，如利用空域或时域的内插在目的端进行丢包的恢复和视频的平滑。空域的恢复使用同一帧的邻近区域来重新组建丢失的碎片；时域的恢复使用前一帧的相应区域来替代丢失的区域信息。

　　还有一种既适于帧内编码又适于帧间编码的方法，这就是使用基于前向纠错的差错控制机制。在这样的机制中，可以在传输的码流中加入用于纠错的冗余信息，在遇到包丢失的情况时，利用冗余信息恢复丢失的信息。它的不足是增加了编码时延和传输带宽。

　　在实践中，笔者采用了动态调整帧问间隔的办法来适应实际的网络状况，即根据报告包的丢失情况动态调整帧间间隔。至于变化的幅度，笔者通过在本地局域网中的实验证明不宜过大，否则会使系统变得不大稳定；笔者采用指数平均的方法进行丢包率参数的计算，给新的丢包率信息以相当小的比例。实验证明，该方法增强了视频系统对网络丢包情况的适应性。

三、局限性及展望

　　对时延、速率以及差错的控制机制的确在一定程度上缓解了视频传输上的质量问题，但其局限性也相应增加了。主要的局限性在于速度和差错控制机制的局限，事实上，这也是所有在异构

网络中进行多播传递时采用基于源端的控制机制所共有的局限性，即在多播的不同树枝上的不同特性信道共享同样的源的码流时，其反馈信息必然只反映了该码流在本地的状况，固而源端必然只能在各种情况的统计下进行折衷处理，结果是低能力的参与者所在的路径过载或高能力的参与者所在的路径视频质量过低。在实践中，选择一组合适的参数并不容易。理想情况下，多播树各个部分的码流在出现不同程度的拥塞时应被分别处理。可能的解决方案是采用视频网关和分层编码。

　　1.视频网关

　　视频网关可将输入视频流的编码方式（如采用X方式编码）进行转换（如转换成Y方式编码），再将转唤后的码流沿多播树向下级转发。例如，可将Motion-JPEG码流转换成H.261或H.263码流再转发。当然，可以在同样的编码算法不同的编码参数间进行转换。

　　视频网关的主要问题是在网络中如何选择合适的位置放置视频网关，以及是动态放置还是静态分布。在实践中，在现有的多播骨干网（Mbone）中静态网关已提供了较好的异构连接效果。

　　2.分层编码

　　另一种在异构网络中多播视频的方法就是在源端将视频流分成多个，每个流有不同的带宽需求。典型的方法就是采用分层编码。

　　考虑两层的情况，典型的基本流包含低分辨率的信息，其他流包含增强信息。传输的基本策略就是将完整的两个码流传入非拥塞的多播树枝中。只在相对拥挤的树枝中传输基本流。源端不断地发送各层码流，并且不对其进行任何速率的控制。接收端依据其所在网络的情况来选择加入与相应的码流层对应的多播组。

三、结论

　　在现有的因特网上进行实时的视频通信是具有挑战性的。这主要是因为IP网络不同于在设计阶段就考虑到服务质量（QoS）的ATM网络，它只提供尽力而为的服务。这种服务对于数据通信是可以满足要求的，但是对于具有实时性要求的视频业务，这种服务为用户承诺的特性就显得太少了。

　　在这种情况下，根本的解决方案是从网络本身入手的，比如使网络提供不同程度的服务保证、采用一定的资源预留、引入流的概念、对不同流的集合进行标已交换，等等，但是这些标准和技术被广泛采纳和使用还需要经过一段较长的过程。因而，在现有的网络上，可以通过使源端或目的端自适应地调整自己的行为，调整视频业务通信量对网络的需求和依赖来适应现有网络。虽然这样的方法并不能解决视频通信的根本问题，但这样的方法的确在现有的实际应用中发挥了很大的作用。

　　通过在笔者参与研制的基于H.323标准体系的视频会议系统中采用以上的自适应控制方法，证实了这类方法对于增强视频系统的适应能力有明显的作用。而且，即使在未来的可以提供多种服务的网络中，这类自适应的控制机制也必定成为应用中必不可少的功能。

摘自《通信标准与质量信息网》