陈 美,汪清清
(中国电信股份有限公司江苏分公司 南京210017)
随着通信技术的不断发展,互联网业务已从满足用户的基本需求转变为满足用户更丰富的消费性和娱乐性需求,视频业务成为主要的互联网应用之一,也是各大运营商竞争的焦点之一。目前,视频业务种类繁多,如在线视频、IPTV、视频监控、会议电视等。
2010年,国务院正式决定加快推进电信网、有线电视网和互联网的三网融合,作为三网融合的重要切入点,电信运营商必将大力发展IPTV、手机影视等视频业务,最终实现以IP网络为统一承载的语音、数据和视频3重业务的捆绑[1]。
对视频业务来说,用户往往通过看视频卡不卡、切换快不快判断业务质量的优劣。IP承载网是一个“尽力而为”的网络,而视频业务是一个需要高带宽、低传输延时和低延时抖动的业务,任何一个环节出现问题都可能导致用户观看视频时出现马赛克、卡顿、响应慢等现象,甚至无法观看。因此,提升视频业务质量、优化使用感知更具迫切性。
三网融合后,视频媒体的交互化是产业发展的必然趋势。IPTV产业形态日趋成熟,产业价值不断提升,将成为三网融合进程中最为核心的主导型业务。本文以IPTV为例,阐述FEC及FCC技术在提升视频业务使用感知方面的应用。
随着IPTV产业链的逐渐成熟,业务需求已从“可用”、“能用”向“好用”阶段转变,能否提供好的用户体验质量(quality of experience,QoE)[1]成为IPTV业务能否可持续发展的必要条件。视频播放的流畅性和频道切换延时是衡量QoE的关键指标。因此,降低节目卡顿概率、提升频道切换响应速度是目前急需解决的问题。
对于节目播放卡顿问题,运营商一般通过分段排查的方式定位故障原因,解决网络设备、平台服务器软硬件故障或优化线路质量。故障从申告到解决需要一定时间,影响了用户感知。目前采用的纠错机制主要是传统的差错控制技术,包括依靠TCP本身所具备的丢包、超时重传机制,或在UDP之上扩展出丢包、超时重传机制等。在网络拥塞严重的网络中,可能导致视频图像质量更加恶化。
对于频道切换延时问题,运营商一般通过优化业务认证流程、使用静态组播树代替动态组播树[2]、提升设备性能[3]等方式降低响应延时。但由于IPTV业务流程、组播技术特点、费用投资等方面的原因,频道切换延时仍较数字电视长。
如何以较小的投入成本、较短的时间提高IPTV业务对网络质量的容忍度、提升频道切换延时使其与数字电视相当,是运营商要解决的重点问题,也是实现IPTV业务质量突破的关键。
直播服务作为IPTV业务中的一项重要业务,一般采用基于UDP的组播方式进行传送。而对于采用TS over RTP格式的IPTV媒体传输过程中的容错纠错,目前国际国内都没有正式的规范,相关的建议和标准草案中主要提到两种措施:丢包重传和前向纠错(FEC),两者的简单对比见表1。
表1 丢包重传和前向纠错技术对比
可见,FEC技术更适合于直播业务,其单向无交互的特点,使其适用于基于组播方式的直播服务场合。
IPTV领域中的FEC算法大多基于异或运算的原理。假设有2 bit的信息A和B,对A与B进行异或运算作为FEC数据,表2列出了FEC分别与A和B进行异或运算的结果。
从表2可以看出,FEC XOR A的值与B相等,而FEC XOR B的值则与A相等。如果在发送数据时,除了发送原始比特位A和B外,将A与B作异或的值作为一个额外的比特位加以发送,则这3个比特位中的任意一个比特位丢失,都可完全恢复原始信息。表2针对的是2 bit的情况,3个或更多的比特位进行异或运算,也可得到同样的纠错效果。
表2 异或运算结果
确定了FEC的核心算法后,还要确定一种模式从原始媒体包中选择合适的媒体包参与FEC运算,如图1所示(参与同一次FEC计算的媒体包和FEC包外框表示相同)。
在图1中,A的做法是每连续5个包作一次FEC编码,而B的做法则是奇数包和偶数包分别作FEC编码。假设网络因素导致媒体包1和2被丢掉了,则对于A来说,总共6个包(5个媒体包加一个FEC包)丢掉了1/3,可能恢复失败,而对于B来说,6个包中只丢掉一个,恢复成功的可能性大很多。
编码后的FEC数据必须采用合适的格式进行封装,封装后发送FEC数据的时机也很重要。假设FEC数据被封装成单独的数据包进行发送,图2给出了两种不同的发送模式。
从图2可以看出,A的发送方式将FEC包均匀分布在输出的码流中,但在连续丢两个包的情况下,如果刚好是圆圈中的两个包丢失,则同一组6个包损失1/3,无法恢复。B的发送方式简单地将两个FEC包放在最后发送,能够抵抗任意位置的两个连续丢包。
除了上述FEC算法外,信息领域内还有一些其他的FEC算法,如常用的RS编码,能够识别出接收数据中的比特误码并加以纠正,但由于IP网络上的数据错误在应用层通常表现为整个数据包的丢失,在视频业务领域内鲜有应用。
图3为江苏电信在IPTV业务中应用FEC技术的解决方案之一,具体如下。
·在省中心和区域中心分别部署直播服务节点。
·中心直播节点和区域直播节点间采用单播方式传输直播码流,同时部署FEC,FEC数据与原始码流共用一个RTP通道。
·区域直播节点从中心直播节点接收直播码流,进行FEC解码和纠错。
·区域直播节点再次对直播码流进行FEC编码,并将码流以组播方式发送给区域中心、边缘节点和机顶盒。
·区域中心发出的FEC数据采用单独通道传输,以兼容各厂商机顶盒。
直播频道切换流程如图4所示。
·首先机顶盒需获取频道的组播地址,耗时一般约几百毫秒。
·根据组播地址,加入该频道对应的组播组,耗时0.1~1 s,与承载网数据设备有关,IPoE较快,PPPoE较慢。
·获取码流的PSI信息,与PAT和PMT的重复间隔有关,耗时约为50 ms。
·等待码流的第一个I帧,通常I帧间隔为2 s,等待I帧的时间平均约为1 s。
·传输I帧耗时一般在300 ms以内,机顶盒接收到I帧后即开始播放。
由图4可以看出,等待和传输I帧的时间占据频道切换时间的绝大部分,应该作为重点优化对象。
FCC技术是在现有架构基础上,部署独立的硬件设备,采用单播方式向机顶盒发送以I帧开头的码流,消除等待I帧的时间,加快频道响应速度。
因此,可在用户侧就近部署频道缓存服务器接收来自组播源的码流,并实时缓存到内存中,缓存数据量与频道码率有关,始终保证缓存中有最近的一个完整块组。当用户进行频道切换时,机顶盒在向组播设备发出加入组播组请求的同时,一并向缓存服务器发送快速切换请求,缓存服务器则将最近一个块组的媒体数据发送给机顶盒。块组以I帧开头,机顶盒收到后可立即进行解码并显示,从而提高用户的体验质量。如果缓存服务器由于负荷过高等原因无法处理机顶盒的请求,则不向其发送任何码流,原有的频道切换流程不受任何影响,机顶盒仍然可以正常进行频道切换。一个块组的数据发送完毕后,缓存服务器停止此次发送行为,机顶盒随后开始处理来自组播设备的实时码流。
图5为江苏电信在IPTV业务中应用FCC技术的解决方案之一。
FCC方案部署后,频道快速切换的流程如下。
·缓存服务器事先加入所有组播组,从组播设备接收各频道的码流进行缓存。
·机顶盒在切换频道时向缓存服务器发起请求,缓存服务器采用单播方式向其发送最新的一个GOP,机顶盒接收并进行解码显示。
·机顶盒接收来自组播设备的频道组播码流,转入常规的处理流程。
实际组网时组播设备可能有多个,缓存服务器和机顶盒可以分别部署到不同的组播设备下,建议在满足容量的前提下尽量靠近机顶盒部署。缓存服务器的处理能力相对固定,其用户容量则受频道数量、频道码率、块组大小和用户观看习惯等因素的影响。
江苏电信对应用于上述方案的FEC和FCC技术进行了实验室测试和现网用户试点。
实验室测试结果表明,10%左右的FEC冗余数据能容错2%的丢包。
选取江苏电信2个地市分公司的用户进行试点,试点结果见表3。
试点情况表明,FEC技术在解决直播卡顿问题中发挥了明显的作用,但在部分极端场景(如丢包率超过纠错阈值)下无法发挥效果。
实验室测试结果表明,在频道视频码率为2 Mbit/s、GOP值为2 s的情况下,频道切换速度降至1 s以内。
表3 江苏电信用户试点情况
选取江苏电信1个地市分公司进行试点,FCC缓存服务器为该地市IPTV平台区域中心节点的一台流媒体服务器,测试结果如下。
·机顶盒在EPG主页,通过频道+/-切换到直播频道,频道切换时长在1 s以内。
·机顶盒直播状态,通过频道+/-切换到直播频道,频道切换时长在1 s以内。
·机顶盒在点播状态,通过频道+/-切换到直播频道,频道切换时长在1 s以内。
·机顶盒在回看状态,通过频道+/-切换到直播频道,频道切换时长在1 s以内。
试点情况表明,FCC技术在提升频道切换速度中发挥了明显作用,部署后IPTV直播频道切换速度与数字电视切换速度相当。
从信息学角度看,FEC的实质就是在传输层产生冗余信息,显然,冗余码率越高,纠错能力就越强,但消耗的系统资源也就越多。而IPTV用户接入的网络带宽是有限的,冗余码率越高,则用于传输媒体码流的有效带宽就越小。在实施时,应实事求是地确定FEC的纠错指标,在保证指标的前提下尽量控制冗余码率。同样地,FCC的效果与I帧间隔有直接关系,提高I帧间隔,可提高FCC设备的容量,降低带宽消耗,但又会影响节目播放效果,实际中应综合权衡。
从电信运营商的资源优势、运营能力角度考虑,视频业务将是电信运营商的业务拓展重点。随着视频应用的日益增多和视频业务种类的拓展,视频业务的竞争也将日益激烈。只有不断提升用户感知,才能在竞争中立于不败之地。
1 姚良,奚溪.三网融合下视频业务质量评估体系的研究.电信科学,2011(3)
2 于婧,贾凤根,张兴明等.组播技术在IPTV中的应用.电信科学,2005(5)
3 张鹏,杨乾斌,张兴明等.支持IPTV用户扩容的频道快速切换设计.计算机工程,2009(2)