基于应用层的IPTV业务质量优化方案

奚 溪，姚 良

（中国电信股份有限公司上海研究院 上海 200122）

基于应用层的IPTV业务质量优化方案

奚 溪，姚 良

（中国电信股份有限公司上海研究院 上海 200122）

IPTV承载在IP网络上，由于IP网络“尽力而为”的特性，IPTV业务往往会受到网络带宽、传输时延、网络丢包等各种因素的影响，导致IPTV业务质量下降。本文对IPTV业务质量进行研究，针对网络的丢包、时延、抖动这些影响IPTV业务质量的主要因素，提出了通过IPTV应用层的优化方案，以适应“尽力而为”的IP网络，进一步提高IPTV的业务质量。

前向纠错；丢包重传；流量控制

1 引言

随着现代网络和多媒体业务的发展，传统的网页浏览、视频下载、邮件发送等业务已经无法满足人们的需求，具有交互特性的IPTV很好地将电视服务和互联网浏览、电子邮件以及多种在线信息咨询、娱乐、教育及商务功能结合在一起，从而得到越来越多的关注。然而，IPTV这种流媒体业务具有信息量大、实时性强等特点。由于传统的IP网络更多考虑的是不保证实时传输的数据通信，而如今要在IP网络上进行实时多媒体业务的传输，将面临许多问题。特别是IPTV采用RTP over UDP的方式传输，不能保证传输的可靠性，因此对于IPTV业务质量的研究和优化是十分必要的。

2 影响IPTV业务质量的关键因素

IPTV业务质量主要表现在：视频播放是否清晰；是否有马赛克、停顿、断流等现象。影响IPTV业务质量的因素有：IPTV头端的编码器、编码速率、TS封包质量、流输出稳定性以及网络传输过程中的丢包、抖动和时延等。在影响IPTV业务质量的诸多因素中，平台流输出的稳定性和网络传输损伤是最为关键的。

在流媒体传输过程中，丢包直接影响了视频音频的解码，会引起停顿或马赛克。过大的抖动则会引起网络设备缓存上溢，或终端缓存的上溢和下溢。缓存上溢会引起丢包，缓存下溢会引起视音频解码的停顿。即使视频服务器码流输出平稳，但如果视频文件编码速率的抖动过大，终端收到的码流速率和消耗的码流速率不匹配，也会引起终端缓存的上溢或下溢。

因此，针对丢包和抖动，应在IPTV平台和终端间引入丢包恢复和避免缓存上下溢的机制。其中，针对组播丢包恢复的机制是FEC，针对单播丢包恢复的机制是ARQ，针对单播避免缓存上下溢的机制是流量控制。

3 流媒体丢包恢复技术方案

3.1 丢包恢复技术原理

为了减少视频数据丢失和错误对解码质量造成不利的影响，需要使用一些错误控制技术来提高视频数据在网络上传输的可靠性。目前主要流行的纠错方案是前向纠错技术和重传技术。

3.1.1 前向纠错技术

前向纠错技术（forward error correction，FEC）是一种通过在信息源增加冗余信息实现丢包恢复的措施。在IP网络里，数据报文的正确性已经由网络层保证，如果出现传输错误，设备、网卡会自动丢弃。所以，这里的FEC应用不是纠错，而是丢包恢复。FEC的数据处理流程如下：

（1）媒体服务器对原始媒体内容进行前向纠错编码，生成冗余信息；

（2）原始媒体数据与FEC冗余数据发送到客户端，可能存在丢包；

（3）终端根据收到的数据进行FEC解码，恢复出丢失报文的完整内容。

FEC无需反馈的机制特点使其适用于IPTV组播应用。

3.1.2 丢包重传

自动重传请求（automatic repeat-request，ARQ）是一种通过丢包反馈重传实现丢包恢复的措施。ARQ的数据处理流程如下：

（1）媒体数据经过编号（如 RTP序号）后发送到客户端，可能存在丢包；

（2）终端根据序号向服务器反馈丢失分组信息；

（3）服务器重传丢失分组。

ARQ的技术需要反馈，因而更适用于IPTV的单播业务。

3.2 FEC技术实现

FEC的实现需要增加两个模块：在流媒体服务器侧增加FEC的编码模块；在终端侧增加FEC的解码模块。

目前流行的FEC算法有很多种，表1列出了一些应用比较多的FEC算法，并且对这些算法进行了分析。

其中，ProMPEG是基于奇偶校验算法，算法简单，但是冗余开销大，效果一般。Raptor编码是预测编码算法，抗突发丢包的能力差。Tornado算法是一种稀疏图码，编码性能很高，但应用不广泛。RS算法基于BCH编码方式，算法简单，解码与丢包位置无关，编解码性能高、并且抗随机和突发丢包能力强，应用也比较广泛，因而本文建议采用Reed-Solomon算法，丢包恢复能力与丢包的位置无关。FEC编码组的RTP报文数和冗余报文数可设定，但是建议不超过100个RTP报文，冗余报文数不超过RTP报文数的5%。

FEC算法模块在流媒体服务器、终端中的位置如图1所示。

表1 FEC算法分析比较

3.3 ARQ技术实现

ARQ的重传反馈有两种方式：一种是通过RTCP方式反馈丢包的信息；一种是通过RTSP的方式反馈丢包信息。考虑到日后分片式流媒体服务器是一种趋势，在单播请求中RTP的地址会有变化，RTCP的地址也同样会跟着变，对于重传请求服务器的刀片定位会有影响。因而建议采用不变的RTSP方式用于回馈丢包信息。

终端根据收到数据包的RTP序号判断是否有RTP数据包丢失，当发现有RTP数据包丢失时，终端以RTSP协议向平台发起重传请求。重传的RTP数据包与原RTP数据包结构相同，终端收到重传的RTP数据包后，在终端侧应有RTP乱序现象，终端应根据RTP序号重新对RTP数据包进行排序。如被重传的RTP数据包在被媒体播发模块解码时仍未收到，则放弃该RTP数据包，不影响媒体播放的实时性。

判断RTP包丢失的依据是：当收到RTP包序号不连续时，即判断有一次RTP包丢失。一次RTP包丢失有可能丢失的是一个RTP包，也有可能是丢失连续的多个RTP包。不管是丢失一个RTP包，还是丢失连续多个的RTP包，终端向平台请求重发的RTSP包只需发一次，RTSP包中包含有一个或多个丢失的RTP包序号信息。针对一次RTP包丢失，RTSP重传请求只需发送一次，无论重传RTP包是否达到，都不应再向平台发起RTSP重传请求，这样可以有效地避免反馈风暴的发生。

4 流媒体传输流量控制技术方案

4.1 流量抖动原因

导致流媒体流量抖动的原因有很多种，视频服务器性能变化、网络线路出现拥堵、网络设备的性能变化都可以导致视频流的抖动变化。抖动会导致网络设备和终端的缓存上溢和下溢，进而引起图像的停顿或马赛克。

目前采用的去除抖动的方式有3种：在流媒体服务器平台侧对输出视频流进行预处理，采用平谷、削峰和shaping的方法降低视频流的输出抖动；在网络设备和终端侧增加缓存空间；采用流量控制技术。本文中采用的是流量控制技术。

4.2 流量控制技术原理

流量控制的技术原理是：终端根据缓存的实际状况，向流媒体服务器平台请求码率增加或减小。

流量控制机制是一种通过终端控制服务器的发送码流速率来达到缓存区调整的方法。采用流量控制的流程如下：

（1）终端实时监测缓存状态，如超过了缓存上溢或下溢的预警线，则向服务器发出缓存调整指令。

（2）服务器根据终端的请求，在规定的码流速率范围内，根据终端需要调整的缓存大小，确定码流速率调整的大小和调整的时间。

4.3 流控技术实现

在平台侧和终端引入流量控制机制，具体的交互流程如图2所示。

（1）终端与平台交互验证是否支持流量控制；

（2）终端进行RTSP信令交互；

（3）终端在发现缓存区溢出的情况下，通过发送进行流量控制的请求，与流媒体服务器进行流量控制；

（4）服务器响应流量控制请求，调整发流的速率。

5 结束语

本文根据现网的IPTV质量分析，提出了影响IPTV业务质量的主要因素是丢包和抖动，并进一步提出了基于应用层的IPTV质量优化方案，对于组播丢包引入FEC的方式，对于单播丢包引入ARQ机制，对于网络抖动引起的缓存上溢和下溢可以采用流量控制的方式。这些优化机制的引入，可以保障IPTV视频的传输质量，有效提高观看IPTV视频组播和点播的质量。

1 RFC3550.A Transport Protocol for Real-Time Applications

2 RFC5510.Reed-Solomon Forward Error Correction (FEC)Schemes

3 RFC2327.Session Description Protocol

4 RFC2326.Real Time Streaming Protocol(RTSP)

2010－07－15）