IPTV智能终端传输系统的设计和实现

单玉峰

(思科系统公司，圣何塞加利福利亚州 美国 95134)

近几年来，随着网络技术的发展和宽带网络基础设施的普及，网络多媒体技术得到了越来越多的关注。世界上许多网络服务商开始部署网络电视(IPTV)[1]和交互式视频应用(Interactive TV)[2]，以家用电视机(计算机或者智能手机)作为主要终端，通过IP协议向用户提供电视节目以及多种交互式数字媒体服务及其增值业务。不同于传统电视单向广播的特点，IPTV的最大优势在于其“互动性”和“按需观看”。为了获得新的用户和抢占电视市场份额，仅仅这两大优势是不够的，新的网络多媒体服务应该提供比当前的电视服务更好的服务质量。针对于视频传输质量来讲，目前公认的IPTV行业基准是播放1个2小时的电影，最多允许1个传输差错。这个非常严格的“应用层”的要求映射到网络层是视频传送的丢包率不应大于1.0e－6。虽然网络服务商在设计网络的时候采用高可靠性部件和各种各样的冗余，但是完全消除网络层的传输故障是不可能的。优化传输中的可靠性是非常有必要的，可以大大降低视频应用的差错率和提高服务质量，以利于和传统电视竞争[3]。本文主要讨论IPTV系统中智能客户端的关键技术以及实现。

1 IPTV传输中的主要技术要求

1.1 IPTV 系统结构

典型的IPTV系统通常包括超级头端(Super Headend，SHE)、区域头端(Reginal Headend，RHE)、视频交换中心(Video Switching Office，VSO)和最终用户等，如图1所示。这些系统分别分布在核心网(Core Network)、承运网(Distribution And Aggregation Network)、接入网(Access Network)以及家庭网络中。SHE通常负责接收原始媒体，通过视频编码后依靠核心网络传送给RHE。RHE通过承运网链接VSO，提供视频服务给最终用户。

1.2 运载网路传输的可靠性

提供视频应用的网络服务商在优化他们网络的时候一方面要保证用户的服务质量，另一方面又要保证自身的最佳经济利益。他们经常超额规划他们的网络，并且假设所有的用户不会同时使用网络，因此对某种服务分配的网络带宽通常要小于所有用户的带宽之和。虽然从经济角度来讲比较合算，但同时也引进了可能的网络拥塞。当网络拥塞发生时，非实时应用例如TCP文件下载，发送端可以采用降低发送速率的办法来避免拥塞。但是实时多媒体应用通常在传送中需要固定的网络带宽，采用这种改变速率的方法会引起用户视频观看质量的下降。因此，解决实时应用的优化方法不是降低传送的速率，而是尽量避免这种情况发生。

图1 IPTV的系统结构

目前IPTV运营商主要提供基于组播的实时节目和基于VOD的点播节目[4]。针对于组播的网络传输设计比较简单，因为运营商掌握所有组播节目的带宽，而且组播使用的核心网络带宽并不随着用户数量的增加而增大，在运载网路设计中可以预留足够的带宽以保证服务质量。对于直播VOD节目，使用的网络带宽会随观看用户的增加而增大，当网络流量达到最大设计流量的时候，服务器应该拒绝新的媒体播放请求，从而避免拥塞的发生。这种办法的好处是只影响1个用户而不会影响其他所有正在接收视频的其他用户，新的用户请求会被推迟到有带宽的时候。

在媒体系统中，应使用视频接入许可控制(Video Call Admission Control)技术来解决网络拥塞问题。通常需要2步来完成视频接入许可控制。第1步是利用RSVP(Resource Reservation Protocol)的核心网(Core and Distribution Network)接入许可控制，如图2，以确保核心网有足够的带宽来传送新的媒体流。具体步骤为:用户通过机顶盒遥控器选择想要看的电影，用户请求(VOD Request)通过运营商的边界集中路由器(Edge Aggregation Router)传送到视频服务器(VOD Server)。VOD服务器发送RSVP信息给用户机顶盒，同时实时跟踪在核心网和传送层的变化。沿着这个路径，路由器执行带宽账户功能(Bandwidth Accounting Function)。如果有足够的带宽支持视频传送，路由器将会批准带宽请求，否则会拒绝。当请求被拒绝时，RSVP－CAC信息将会被送回视频服务器，然后视频服务器送给用户拒绝信息或者忙音。

图2 核心网接入许可控制

第2步接入网络的许可控制，用来确定接入网络是否有足够的带宽运载请求的视频数据。在收到用户VOD请求后，视频服务器发送1个带宽查询信息给策略服务器(Policy Server)。策略服务器管理着所有的接入用户，根据它掌握的用户信息，视频服务器的请求可能被批准或者拒绝。第1步和第2步可以同时进行。

当核心网和接入网的接入请求得到许可后，视频服务器就可以发送用户请求的电影，同时又可以保证不影响其他用户的观看质量。

1.3 纠错技术

大多数系统运营商的用户接入网络丢包率在1e－4级别。而视频系统对丢包率的要求是小于1e－6。因此为了保证理想的视频传送质量，一定的网路纠错技术是必不可少的。目前比较成熟的网络纠错技术有2种:自动重传(Automatic Retransmission Request，ARQ)和前向纠错编码(Forward Error Correction，FEC)，这2种方法都有各自的优点和缺点。在有些IPTV系统中采用ARQ，有些系统运营商采用FEC，还有的系统结合使用这2种方法[5]。

1.3.1 自动重传ARQ

如图3所示，自动重传技术是由接收端驱动的，在网络传输过程中，当接收端检测到有丢失的数据包，接收端就会发送1个请求给服务器请求其重发丢失的数据包。服务器在接收到用户的请求后，重发丢失的数据包。这种方法的优点是只传送丢失的数据包，占用网络带宽较少，它的缺点也很明显，需要发送请求重传信息给服务器，有传送延迟 (数据包的网路往返传送时间，Round Trip Time)。在多播环境中，特别是用户比较多的时候反馈信息会拥塞发送服务器，因此在多播时，通常需要配备专门服务器用来处理重传请求信息和发送丢失的数据包。在点对点的通信，例如视频点播，这种方法比较有效。

图3 自动重传

1.3.2 前向纠错编码 (FEC)

不同于自动重传，前向纠错技术是由发送端驱动的，发送者在发送视频数据包的同时，也发送一些经过编码的数据包(如图4中的“R”，编码包的数量需要根据网路丢包率来决定)。在网络传送过程中，如果有数据包丢失，接收端就会尝试利用接收的编码包来恢复丢失的视频包。这种方法的优点是不需要发送反馈信息给发送者，仅仅是从服务器到客户端的单向通信。缺点是服务器不知道送多少编码数据包是合适的，如果送的多，有利于恢复丢失的数据包，但同时增加了网络带宽的占有率。如果网络丢包率很低，这些带宽都浪费了。如果送的少，可能并不能用来恢复所有的丢失的视频数据包。

图4 前向纠错编码

一种比较好的办法是结合这两种技术的优点，例如服务器在发送媒体数据包的同时，发送少量的纠错编码包，如果在传送过程中出现丢包，接收端首先利用纠错编码包重建丢失的数据包，如果不能重建所有的丢包，接收端可以利用自动重传来修复剩余的丢包。

1.4 快速频道切换

快速频道切换主要是针对组播频道来讲的，频道切换时间定义为从用户按下遥控器按键到第1个视频图像在电视上显示的时间间隔。在现在的非IP电视中，频道切换的延迟非常小。在IP电视网络中，每1个电视频道就是1个组播数据流，IP机顶盒利用IGMP组播协议在组播数据流之间转换。当用户发出频道切换的请求时，IP机顶盒首先送出IGMP“离开”信息(IGMP Leave)给正在播放的频道，然后发出IGMP“加入”信息 (IGMP Join)给新的频道。一定时间的延迟后，新频道的组播数据流就会传送到机顶盒。当机顶盒接收到需要的视频解码信息后，机顶盒解码接收的视频数据包，然后把新频道的视频显示在电视机上，完成1次频道切换。

影响频道切换的几个主要因素:

1)IGMP协议信号延迟:IGMP协议的“离开”和“加入”信息需要传送到相应的边界路由器以断开旧的和接收新的组播数据流。

2)MPEG解码延迟:为了能够解码MPEG数据流，解码器需要得到节目信息表(Program Specific Information，PSI)，特别是节目分配表(Program Allocation Table，PAT)。根据MPEG标准中，2个PAT表在数据流中的距离可能会高达500 ms。也就是说解码器在最坏的情况下可能会接收长达500 ms的数据才能得到想要的PSI信息。

3)视频I帧获得时间:在MPEG视频编码的时候，通常会把1组原始数据帧(Group of Picture，GoP，一般12～15帧)作为1个编码对象。MPEG可以把数据帧压缩成3种格式:I帧(Intra－Frame Coding，可以单独解码);P帧(Predicated Frame Coding，需要依赖I帧或者前面的P帧解码);和B帧(Bi－directional Coding需要依赖前后的I或P帧解码)。为了节约传送带宽，在MPEG视频压缩标准中，通常1个GoP只有1个I帧，其他的都是P或者B帧。但是接收端需要解码I帧后，才能解码其他的P或者B帧。I帧的延迟是根据GoP的大小来决定的，在典型的广播系统中，通常每隔500 ms发送1个I帧(在H.264编码中也可能采用多于1 s的GoP)。因次在频道切换时，I帧的延迟是比较大的一个影响因素。

4)加密系统密码获取延迟

在1个典型的加密系统(Conditional Access System，CAS)中，权利控制信息(Entitlement Control Messages，ECM)和权利管理信息(Entitlement Management Messages，EMM)被用来加密要传送的媒体。这些信息每隔一段时间被嵌入到传送的MPEG媒体中，机顶盒必须接收到ECM和EMM才能解密MPEG数据流。解密密码的获取也增加了频道切换的延迟。

以上的主要延迟综合起来，IPTV用户的频道切换时间可能会达到几秒钟。相比于现在非IP电视的少于1 s的频道切换时间，几秒钟的切换时间是不能容忍的。为了降低以上谈到的延迟，相应的快速频道切换技术必须包含在IPTV系统中。

1.5 用户视频质量的监控和报告

当系统运营商推出新的视频服务的时候，他们希望了解到每个用户的服务质量如何，用户的满意程度直接关系新服务的成败。为了了解用户的视频观看质量和维持高质量的服务，系统运营商通常会要求客户端能实时提供相应的反馈信息[6]。这些信息会有助于系统运营商优化自己的网络和提供相应的新服务。通常运营商有专门的服务器接收这些报告然后进行分析。因此客户端开发者应该把能够收集和反馈用户服务质量信息作为一个重要的功能来实现。

2 IPTV智能客户端设计和实现

适用网络发展的要求，结合思科强大的网路技术力量，推出了一整套的网络视频解决方案。针对IPTV系统来讲主要有CDS－TV，VQE等等，这些IPTV系统支持直播VOD、组播频道、快速频道切换、网路传输纠错以及复杂的媒体存储和系统管理等等。

在这套系统中，设计和实现了一个基于国际标准的智能传输客户端开源软件VQE－C，任何开发商都可以直接利用思科的VQE－C源代码开发智能客户端。这些客户端可以无缝地和思科上述的IPTV服务器端交互，大大节省开发商的系统开发时间。由于采用国际标准，因此可以兼容任何采用相同标准的系统及服务器。并且思科在推出新的服务器端的应用时，会同时推出升级的客户端VQE－C的新版本，客户端开发商只要重新编译一下新的VQE－C就会支持新的应用，而不需要再进行新的费时开发以支持服务器的新功能。VQE－C客户端的配置也非常灵活，它提供1个系统配置文件，通过改变配置文件可以满足各种各样的应用。

VQE－C客户端是基于Linux平台使用C语言开发的，任何运行在Linux上的应用均可以很方便地使用它。VQE－C软件包的源代码可以从思科的网站上免费下载，它提供的功能如下:

1)支持组播(multicast);

2)支持基于RTSP协议的直播VOD;

3)支持基于MPEG CoP#3的前向编码纠错FEC;

4)支持基于IETF标准的ARQ的网络纠错功能;

5)支持基于IETF标准的快速频道切换;

6)支持基于RTCP协议的用户视频质量的监控报告;

7)数据传输支持RTP和UDP;

8)支持网络地址转换(Network Address Translation，NAT)。

这些功能都集成在一个开源的软件包中，并且提供系统配置文件来设置不同的应用需求。开发者可以把VQE－C想象成网络接口(Network Socket)编程的一个替代层(如图5所示)。这个替代层可以完成上述描述的功能，并提供简单易用的编程接口。在组播环境中，如果IPTV系统需要支持快速频道切换和网络纠错，需要在接入网中部署单独的VQE－S服务器。在直播VOD环境中，VQE－S服务器是思科视频播放服务器CDS－TV中的一个服务器进程。

3 如何集成到用户客户端

图5 VQE－C在系统集成中的位置

VQE－C模块可以运行在Linux内核模式(Kernel Mode)或者用户模式(User Mode)，并提供了一系列的应用编程接口来帮助开发者使用VQE－C的功能。不管运行在内核模式还是用户模式，应用编程接口的调用都是一样的。VQE－C模块在客户应用系统中的位置可以参考图5。开发用户需要把VQE－C集成到IPTV客户端才能使用VQE－C的功能。

3.1 初始化VQE－C

不管是对直播或者是组播用户，集成VQE－C的第1步是在客户端系统启动的时候初始化和运行VQE－C，并且创建相应的“调频器”(Tuner)。每1个调频器就是1个VQE－C数据的接收端。创建的调频器数目可以根据用户的需求来决定，可以简单理解为创建的调频器的数目应该是用户同时接收的媒体流的数目。例如，如果用户需要一边看电视一边记录另一个频道，那么就需要创建2个调频器。

VQE－C初始化时API的调用步骤:

1)vqec_ifclient_init():初始化VQE－C，处理系统配置文件。

2)vqec_ifclient_start():启动VQE－C的事件处理器(Event Loop)，这个API调用并不返回，一般需要建立1个线程来单独运行这个事件处理器。

3)vqec_ifclient_tuner_create():创造调频器(Tuner，VQE－C使用了传统电视调频器的名字用来标识VQE－C中频道的数据接收端)。可以简单的理解为1个视频接收终端，Tuner创建的数量定义在系统配置文件中。

初始化完成后，VQE－C作为1个线程运行在客户端中(例如机顶盒)，中间件可以调用VQE－C提供的API来完成需要的功能。

3.2 VQE－C 接收媒体流

在完成对VQE－C的初始化后，用户就可以使用VQE－C提供的服务。如果用户需要接收某个频道的数据流，中间件需要调用以下API绑定到这个数据流。

vqec_ifclient_tuner_bind_chan():绑定API，绑定调频器到1个正在播放的视频流或者1个频道。当VQE－C绑定1个组播频道后就自动开始接收数据。

对于组播数据流，上述API的调用会发出组播“加入”命令到需要观看的频道，对于直播VOD客户来讲，在调用绑定API之前需要调用另外1个针对直播的API以获得频道信息。

vqec_vod_session_create():该API通过调用VQE－C RTSP客户端来建立1个服务器端的会话(Session)。并且获得频道的信息。利用这个获得的频道信息，客户端调用绑定API，然后调用VQE－C API发送RTSP播放请求给VOD服务器。

3.3 中间件接收视频数据给解码器

完成上述的频道绑定(和播放)后，VQE－C已经开始接收媒体数据流，并且根据配置文件自动执行纠错功能和快速频道切换功能，中间件需要调用下列API把VQE－C接收的数据传送给解码器。

vqec_ifclient_tuner_recvmsg():机顶盒调用这个API接收经过VQE－C处理的数据包，数据包被传给解码器进行解码。

在VQE－C的运行过程中，VQE－C监控服务质量，根据配置这些信息可以被发送到VQE－S作为运营商的服务质量评估。

3.4 技术文档

在VQE－C的软件包中包含了3个参考文件。系统集成指南提供了详细的API介绍和如何集成VQE－C到你的开发系统中。系统配置指南提供了如何配置系统文件会得需要的功能和参数配置。CLI命令指南提供了如何使用VQE－C的命令行来调试VQE－C的输出。

3.5 项目实现

该客户端被成功的应用在世界上许多的IPTV运营商中。图6列出了VQE在比利时电讯IPTV系统中的拓扑结构[7]。IPTV Set－Top Box运行 VQE 客户端，Retransmission Server运行VQE服务器软件。

图6 比利时电讯采用VQE的拓扑结构

图7显示了VQE用户质量监控系统检测到的从周五到周一4天的纠错包数据流量，这个图表相关的用户数是1.83万使用VQE的IPTV用户。

图7 VQE用户质量监控系统检测到的纠错包的数据流量

4 结束语

在本文中，描述了1个智能IPTV客户端所需要的技术以及它的实现，并且提供了1个开源的客户端软件。这个软件可以大大提供开发商的IPTV客户端的开发时间，同时开发的客户端可以无缝的和思科的服务器进行交互，也可以和遵循同样标准的第三方服务器交互，大大扩展了客户端的使用范围和支持的厂商。这个系统现在已经得到了世界上许多运营商的支持，开发商可以利用该系统作任何需要的二次开发。

[1]严华.IPTV 技术与发展探讨[J].计算机应用，2008(2):59－61.

[2]夏勇，何晶.融合网络宽带IP互动电视技术方案设计[J].电视技术，2010，34(10):9－13.

[3]EVANS J，BEGEN A C，GREENGRASS J，et al.Toward lossless video transport[J].IEEE Internet Comput.，2011，15(6):48－57.

[4]BEGEN A C，GLAZEBROOK N，STEEG W V.A unified approach for repairing packet loss and accelerating channel changes in multicast IPTV[C]//Proc.IEEE Consumer Communications and Networking Conf(CCNC):Special Session on IPTV towards Seamless Infotainment.Las Vegas，NV:IEEE Press，2009(1):1－6.

[5]LI Zhi，ZHU Xiaoqing，BEGEN A C，et al.Forward and retransmitted systematic lossy error protection for IPTV video multicast[C]//Proc.Packet Video Wksp.Seattle.WA:IEEE Press，2009(5):1－9.

[6]BEGEN A C，PERKINS C，OTT J.On the use of RTP for monitoring and fault isolation in IPTV[J].IEEE Network，Special Issue on Improving Quality of Experience for Network Services，2010，24(2):14－19.

[7]MIGNON M，BOUCKHOUT K，GAHM J，et al.Scaling server－based channel－change acceleration to millions of IPTV subscribers[C]//Proc.Packet Video Wksp.Munich，Germany:IEEE Press，2012.