百视通肖友能:从IPTV到OTT TV的技术演进
流媒体网| 2013-11-22

    【流媒体网】消息:2013年是IPTV发展的十周年,同时,2013年也是OTT开始回归理性、寻求产业共赢的新起点之年,2013年,对于中国的电视新媒体的发展均具有重要的里程碑意义。

    11月21日-22日,流媒体网“厦门论道IPTV/OTT”高峰论坛正式召开,今天的主题是“在一起:OTT融合创新,合作共赢”。
 
    百视通新媒体股份公司首席架构师肖友能参加此次论坛并发表了讲话,他的演讲主题是“从IPTV到OTT TV的技术演进”。


     据肖友能介绍,IPTV是网络和视频流严格管理的业务,IPTV的网络和视频流是周密规划、严格管理、严格可控的,在专网内,网络的带宽和业务被严格规划,用户使用IPTV业务的带宽可以保证,同时,为了保证视频码流在网络中平稳传输,视频编码采用了CBR。
 
    肖友能表示,OTT业务由视频网站主导的业务,一开始并没有电信运营商的参与,不是一项电信业务,而是一个标准的互联网业务。OTT业务开展的视频编码是VBR,VBR编码是基于视频内容本身的活动性进行码率分配和速率控制的,码率波动范围较大,波动的视频码率和波动的网络带宽交织,使得在互联网中传输VBR视频变得更加复杂。

    互联网视频的技术体系是偏向视频技术领域还是偏向互联网技术领域?肖友能认为是偏向互联网技术领域,而且需要思想观念的转变。事实上,目前的互联网电视的CDN,是基于Apache或者nginx这样的开源软件开发的,效率比传统的IPTV Video Server高得多,这两者的技术思路和体系完全不同IPTV信令用的是RTSP,数据传输用的是基于UDP协议的单播或者组播

    单码率VBR是否可以开展OTT TV业务?肖友能表示,单码率VBR可以开展OTT TV业务,但不是一个好的选择,单码率互联网电视业务一般是用带宽最低的用户的值作为业务开展的基准码率,所有的宽带用户看到的都是质量一样的内容。而多码率的互联网电视业务根据每个用户的网络带宽,最大限度的利用带宽,基于带宽不同,为用户提供差异化的服务。

    最后,肖友能得出三点结论:

    1.IPTV和OTT TV都是以视频服务为主的业务形式,但由于两者诞生的时间不同、业务运行的网络环境不同、业务实施主体的背景不同,在技术体系上有较大的差别。

    2.IPTV更多体现出一种网络周密规划、严格管理的电信业务的技术特征,而OTT TV更多体现出网络无关、快速扩张的互联网业务的技术特征。

    3.OTT TV和IPTV的协同发展。IPTV经过8年的运行,技术体系成熟稳定,业务模式清晰,全国已经有2500多万用户,处在稳步发展中;OTT TV技术体系较年轻,吸取了互联网技术的精华,业务更灵活,部署更敏捷,正处在蓬勃发展中。

    演讲全文如下:

很高兴有机会和大家分享从IPTV到OTT TV的技术演进。关于IPTV技术体系,在座的各位同仁一定非常熟悉,很多人见证了IPTV产生、发展、壮大的过程。有些人还亲自参与了IPTV各项标准的制定。因此,在今天的报告中,关于IPTV这部分,会讲的比较简单。OTT TV或者说互联网电视、互联网视频,是最近几年兴起的一种视频业务形态,正处在加速的发展中。支撑互联网视频业务的技术体系是怎样的?它和IPTV的技术体系有什么差别?

    造成IPTV和OTT  TV不同的根本原因是在中间技术上的传输网络。由于IPTV和OTT这种业务模式网络环境不一样,导致他们在技术上有非常大的差异。我们接下来就从网络开始看。

    一、IPTV与OTT TV不同的根本原因在于传输网络

     1.IPTV是网络和视频流严格管理的业务

 
 
图1

    我们看IPTV和OTT  TV的网络环境。IPTV最初是由中国电信、百视通等主导初创的一项电信业务。和所有的电信业务一样,在业务上线前,都会做周密的规划,严格管理、严格可控的。它在专网内运营,网络的带宽和业务被严格规划,用户使用IPTV业务的带宽可以保证。视频采用恒定码率CBR编码,确保视频编码的峰值始终在带宽的约束范围内。IPTV就是在这样的网络环境下开展业务规划。图1中有三个著名的接口,C1,C2,C3,其中C2是用于原数据下发的接口,C3接口是业务数据同步的接口。这些接口在全国各地的系统上有差异,但基本结构就是如此。

    2.OTT开展的网络环境

    我们看一下OTT,它的诞生环境和IPTV不一样,因为OTT从一开始由视频网站主导的业务,一开始并没有电信运营商的参与,不是一项电信业务,而是一个标准的互联网业务。OTT业务是在开放互联网中开展的业务,用户接入网络的带宽不是严格可控的,是随时间波动的。众所周知,我们在网络上可以看新闻,可以去上网,把视频搬到网上,互联网就做了这个业务。相对于传输网页这种业务模式来说,视频的传输在互联网上并不是非常的适合。因为大家在用视频业务的时候需要建立一个标准的信号,这种视频能比较可靠的传输到用户的终端,达到用户想要的体验。互联网的带宽是大家竞争共享的带宽。还有一个就是在编码方面,早期家庭的带宽比较小,对于互联网的运营商,比如优酷、土豆等,这些带宽的成本占到了三分之一,是一项非常大的成本。

    OTT业务开展的视频编码——VBR  
 
图2

    VBR编码是基于视频内容本身的活动性进行码率分配和速率控制的,码率波动范围较大,我们就可以看到一个CBR码率波动比较大的码格,在带宽可以保证公网的情况下可以进行传输,传输的环境变得很复杂。作为互联网的运营商或者互联网视频的门户网站必须解决这些问题。因为这些人他们本身的技术背景是做互联网网页,自然而然的就会用互联网的理念和方法改造视频,让这种视频业务可以在互联网上进行传输,进而形成了新的互联网电视的技术体系。我们今天坐在这里更多的是做视频相关的技术,当我第一次看到这种互联网视频技术体系的时候,也花了一段时间去理解它。如果说在互联网视频的技术体系上要做选择的话,我认为它更多的是一个互联网的技术体系。对于一个做互联网的人来说,如果他去看互联网视频的话,他就非常理解为什么要这样做。用互联网的方法去改造传统视频,他们为此做了很多的工作。

    视频的HTTP化

    我总结了一下,其中最关键的两点:第一就是HTTP化,在HTTP的时候数据本身就进入了UPP的单播或者主播。因为在互联网业务上服务方或视频门户网站和用户之间通过很多的交换机,这些交换机本身就不是互联网运营商可以掌控的。一般来说这些交换机是开放的,使用HTTP可以使用门户视频,因为网络的带宽在波动,在原来HTTP主动推的情况下,是没有办法成立的。所以在这种模式下,大家用的方法是用终端来拉这种方式的。我们就是点击一个网页,这个网页的内容来下载内容。这是比较传统的方法。

    什么叫拉动数据终端,用户对自己的情况非常的清楚,HTTP另一个方面就是流式视频资源化,将一个完整的视频根据时间切成片,每一片都是一个资源,有独立的URL,终端请求是基于资源,而不是基于节目。
 

 
图3

    我们来看一下什么叫资源化?图3显示的是新浪的一个截图,在脚本里有自己独立的地址,有些可能是图片的地址等等。整个新浪的首页其实就是一系列语言资源的集合。将一个节目的视频流按照固定的时间片,比如说,按照苹果的规范化建议是10秒,我们就切,每一个片段自己都可以独立播放,有独立的地址URL。比如我有一张我儿子的相片,这张相片可以放到QQ空间上,可以放到微信上,资源还是一个资源,但是因为应用的场景不一样,所以目的不一样。所以资源是可以反复利用的。在互联网的外部页面上,资源是通过M3U8文件来进行描述的,来描述组成这个视频的界面。就如www.sina.com.cn这个web内容,是由许多其他URL标识的资源构成一样的道理,由HTML来描述,互联网视频的内容组织是通过m3u8文件来描述的。举个例子,一段视频经过资源化大概就变成了以每个独立的资源,比如《致青春》,很多用户不喜欢看片头,在给用户升成这个业务的时候,我们可以给用户直接过渡到正片里,就不用看片头了。再比如,通过分析,我们发现这个人可能是家里有小孩的人,这个电影可能有的镜头比较暴力,不适合小孩看,在播这段视频的时候,我们可以通过描述软件,把比较暴力的那段内容对应的描述文件删掉。总之,通过这种视频本身的资源化可以非常灵活的去组建业务。

    多码率自适应应对互联网带宽变化

    另外一个方面就是完全资源化,在互联网上另外一个限制条件就是码率的带宽是在不断的波动。在互联网视频里采用的是多码率自适应应对互联网带宽变化。在公共互联网中传输视频,使用的另一个手段是多码率,即将一个节目,同时编码成多个码率进行切割,在用户播放的时候,用户的终端是可以不同的去检测离我最近的服务器的带宽,然后根据我终端带宽的情况向服务端去请求最匹配的码率。通过这种方式来使带宽和码率之间有一个最好的平衡,或者说最好的用户体验。

    Apple的HLS规范

    目前互联网最主要的规范是苹果在2012年发布的HLS的规范,在这个规范里定了一个标准的互联网组成部分。第一个是天生为互联网设计,只要网络能支付HTTP协议,视频业务就可以开展;还有一个就是多码率;媒体数据按时间切片,多码率在切片的边界可以平滑切换。在多码率方面是通过M3U8来描述的。有三种码率,分别是ABC,接下来是2.0的M3U8,通过这个来解决多码率和资源化的问题。

    二、OTT和IPTV的技术对比

    前面我们主要解释了一下互联网视频技术上一些关键点。接下来我会把OTT和IPTV的技术体系做一个比较。通过视频编码、多码率、内容注入、CDN分发、直播、EPG进行比较,通过比较我们可以看到互联网视频和IPTV在技术体系上到底有一些什么差别。

    1.视频编码 
 
图4

    首先视频编码可以看到,IPTV采用的是恒定码率CBR进行编码,速率控制模型相对简单,适合在带宽规划的专网中传输。OTT用的是变码率VBR方式编码,速率控制主要基于视频内容本身,编码效率高,波动大。CBR是改革开放之前讲究的公平,VBR讲究的是效益。图4是中国电信广州研究院提供的一个CBR和VBR的码率测试,我们可以看到,比较的对象是7.5兆的CBR,在大部分情况下,2.3兆的VBR的码率是和7.5兆的CBR是比较接近,对于4兆的VBR来说都胜过7.5兆的CBR,所以效果是非常的明显的。

    有一些运营商用单码率的VBR是不是可以开展视频的业务?单码率的VBR本身是可以开展视频业务,但不是非常好的选择。如果运营商做带宽4兆或10兆,如果是单码率满足用户的需求,我们显然要有4兆的带宽作为基本。就相当于10兆、50兆的用户享受的视频体验其实和4兆带宽的宽带用户的体验是一样的。对于高带宽的用户来说并没有充分利用他们的带宽。如果我们用多码率的方式来开展互联网视频业务的话,对于不同的用户基于不同的带宽则会享受到不同质量的视频服务。我们可以基于带宽对用户开展差异化的服务,使宽带资源充分的利用。

    2.内容注入

    我们再看一下内容注入方面,内容注入指牌照方的内容进入到运营商CDN或者内容管理系统。IPTV采用C2的接口进行内容注入,其通过XML消息交互信令以及采用FTP的方式,从牌照方下载媒体文件。OTT TV则是采用HTTP回源的方式获取内容,精髓是基于HTTP的“拉(PULL)”方式,直接给用户提供的是靠近用户边缘的体验。

    回源方式是OTT TV内容注入的技术

    如果在边缘设置节目的话,就可以直接给用户提供服务。如果边缘CDN没有被节目化,就会产生回源。回源的方式本身就是源自互联网的网页头像视频,因为回源方式非常适合大规模的部署。所以用回源的方式开展IPTV和OTT业务的时候,我们就不需要从内容注入到CDN上,我们很快速的可以进入到放号阶段。内容注入的行为是在用户看节目的过程中切入的,在节目没有的时候就会产生回源,一直回源到牌照方的节目,然后给用户提供节目。用回源有一个很大的优势,就是节省带宽。基本上是符合我们通常所说的二八定律。也就是说我们没有必要把所有的内容都放到边缘CPU这个节点,因为这个用户使用的概率很低。

    用户点播回源分析     
 
    图5

    道牌照方侧回源在什么情况下发生:当一个节目在运营商CDN中没有缓存,第一个用户点播这部节目的时候,会发生回源。可能不同的人对安全有不同的理解,一旦回源之后会在用户上的CDN上有缓存,第一个用户点播这部节目的时候就会发生回源,之后再有用户点播这部节目,则不会到牌照方侧回源,而由运营商的CDN直接提供服务。到底多少比例的用户的点播会产生回源呢?按照目标50000用户规模的模型测算,设牌照方为OTT TV准备的全量节目是50000小时,通过图5的测算我们可以知道,用户看电视的时间大概是20634000小时,所以用50000小时除以20634000小时得出平均的回源率为0.00242,即千分之二左右的点播会产生回源。我们进一步考虑,20%的热播内容可以满足八成以上的用户点播,热播内容的回源率是:50000小时x20%/ 2063400小时 = 0.000485,即只有万分之四的热播节目会产生回源到20%的热播内容可以满足八成以上的用户点播。

    回源对用户体验影响的分析

    回源对用户体验的影响主要体现在延时上,造成延时的最根本原因是传输路径上的缓冲和传输距离,在使用专线的情况下,专线点到点之间传输延时主要是光的传输延时,这一部分几乎可以忽略不计。根据百视通进行的大量测试,用专线传输信号到江苏的延时,平均是15毫秒,传输到新疆、黑龙江的延时,平均是50毫秒。全国其他地方传输信号的延时,应介于两者之间,由于一些额外操作,实际延时大于光的传输延时。根据百视通实际测试的专线环境下,用户点播通过回源和不通过回源比较,起播速度平均大概延时200毫秒。

    总的说来,只有极少部分用户的点播会受到回源的影响(千分之二的一般点播或者万分之四的热播);即使受到了影响,影响也只是延时了200毫秒起播。此外,有线电视的正常起播是2000毫秒,OTT正常起播时间更长,一般为4000毫秒。200毫秒的增加时间相对4000毫秒的基数,用户几乎不能明显感受到。

    3. CDN分发比较

    IPTV和OTTTV  CDN分发也不一样,IPTV是基于传统的视频分发理念,采用服务端PUSH的方式。OTT TV是基于互联网内容分发的理念,采用的是终端PULL的方式。IPTV的CDN数据播发采用UDP单播或者组播,采用RTSP协议做流控机制。OTT TV的CDN用的是互联网的开放的软件技术和硬件平台,由于OTT TV CDN分发机制的原理,使其CDN的开发逻辑更简单,天生支持CDN的分层部署。目前互联网公司一般是基于Apache或者nginx这样的开源软件开发回源CDN,回源CDN本质上是一个应用服务器。在硬件方面,同许多互联网公司一样,回源CDN使用标准的PC服务器,而不需要使用专用设备。互联网技术和开源软件降低了CDN开发的门槛。

    4.IPTV和OTT TV的直播比较

    在直播方面的比较。IPTV和OTT TV直播的技术手段完全不同。IPTV直播基于UDP组播,是点对多点通信,要求从视频服务器到终端的所有环节路由器都支持组播。OTT TV的直播采用和点播完全一样的技术。是基于HTTP PULL的点到点通信。因为在OTT的环境下是不适合做组播的。在OTT TV用的最多的是提供最多的编码流,完成直播。一般的OTT TV直播时延大于IPTV的时延。

    5.EPG的比较

    IPTV,终端基于Linux操作系统和浏览器,EPG的解析和呈现由浏览器完成,EPG服务器是典型的web应用服务器,EPG采用的是B/S技术开发。而OTT方面,终端主要基于Android系统,EPG是作为Android系统的一个应用,EPG服务器提供HTTP服务,但不是用HTML组织数据,其采用C/S技术开发。

    总的来说,IPTV的EPG组织方式是:IPTV的EPG是基于Brower-Server,即BS方式。终端是Linux机顶盒,Linux上运行的主要是一个浏览器,通过HTTP请求从服务器获取HTML脚本,然后解析、渲染、呈现;其在服务器端是提供的是一个个HTML (web)页面;IPTV服务端EPG页面的生成方面,其EPG页面是由两种元素构成的:EPG的模板和EPG元数据,而EPG模板是一个HTML的脚本,定义了EPG的呈现方式和布局,EPG元数据决定了用户内容本身,元数据主要是存储在数据库中的记录或者图片服务器上的图片,此外,EPG模板和EPG元数据耦合,形成一个HTML web页面。

    OTT TV的EPG的组织方式

    OTT的EPG是基于Client-Server,即CS方式:终端一般是Android智能机顶盒,在Android终端上运行牌照方业务的APK,该APK的开发遵循Android Application Framework。在APK上通过各种控件,如TextView、ImageView、ProgressView等,确定EPG的布局和呈现;在服务器端提供的是HTTP的服务,而不是HTML 页面(web页面),用户每进入一个页面,向服务端发送请求,服务端将填充该页的元数据(文字、图片)返回给终端,终端将元数据按照APK中定义的格式和布局呈现出来;在CS的模式下,没有IPTV下的EPG模板概念,它的功能被终端的APK所包含。

    三、结论

    IPTV和OTT TV都是以视频服务为主的业务形式,但由于两者诞生的时间不同、业务运行的网络环境不同、业务实施主体的背景不同,在技术体系上有较大的差别;IPTV更多体现出一种网络周密规划、严格管理的电信业务的技术特征,而OTT TV更多体现出网络无关、快速扩张的互联网业务的技术特征;OTT TV和IPTV是协同发展的,IPTV经过8年的运行,技术体系成熟稳定,业务模式清晰,全国已经有2500多万用户,处在稳步发展中,而OTT TV技术体系较年轻,吸取了互联网技术的精华,业务更灵活,部署更敏捷,正处在蓬勃发展中。

    更多嘉宾演讲,请关注厦门论道专题:http://meeting.lmtw.com/20131121.html

责任编辑:lmtwadmin

分享到:
版权声明:凡注明来源“流媒体网”的文章,版权均属流媒体网所有,转载需注明出处。非本站出处的文章为转载,观点供业内参考,不代表本站观点。文中图片均来源于网络收集整理,仅供学习交流,版权归原作者所有。如涉及侵权,请及时联系我们删除!