互联网电视技术方案分析与比较

夏勇

（国家广电总局广播科学研究院互联网技术研究所）

 

摘要：

互联网电视作为一种新的内容服务方式正在快速发展。本文详细介绍了互联网内容传输技术发展历史，总结了互联网内容传输技术的三种方式。并针对目前国外主要的4种互联网电视技术方案进行了分析，重点研究了其中的关键内容，优势和不足。

关键字:

互联网电视 流媒体 传输 方案

 

1． 互联网内容传输方式的转变

在几年以前流媒体传输领域就出现了一种发展趋势，流媒体传输由传统的RTSP MMS RTMP 等协议在线服务向纯粹的HTTP下载转变。现在已经有许多视频网站采用HTTP传输方案进行媒体内容的传输，形成这种转变主要有以下几个理由：

CDN以及服务器主机提供的网页下载服务比传统的媒体流服务要便宜；

传统的媒体传输协议通常很难穿过防火墙或是路由器，因为它们主要是基于UDP协议不定端口传输，而HTTP协议没有这个问题，HTTP基于80固定端口，网络设备对80端口默认支持；

HTTP方式媒体传输不需要特别的缓存或代理；

通过HTTP封装将数据传给用户比其他方式更加方便及便宜；

即使流媒体传输协议是设计用来专门传输媒体的，但事实上是互联网是基于HTTP方式来建设和优化的。这便产生了一个有趣的问题，“为什么要整个互联网去适应媒体传输，而不是让媒体传输适应互联网”。

 

2． 互联网内容传输三种形式

互联网上媒体传输主要有三种类型：传统流媒体、渐序性下载及自适应流媒体传输。

2.1 传统流媒体

RTSP协议是一个典型的流媒体传输协议，也是一个有状态的协议。有状态的意思是指从客户端连接上流媒体服务器的那一刻起，一直到客户端断掉与流媒体服务器端的连接，流媒体服务器一直保持着与客户端的连接状态。客户端通过play、pause、teardown等命令来与流媒体服务器进行通信。

在客户端和服务器端建立连接之后，服务器端开始稳定发送小数据格式的媒体流，传输协议通常采用RTP协议，RTP数据包是1452字节，这就意味着在一个1Mbps视频流中，每个数据包包含大约11毫秒的节目。RTSP协议既可以基于UDP传输也可以基于TCP传输。UDP比TCP更容易被防火墙或代理服务器阻隔，但是TCP容易产生延迟。

 

从另一个方面来说，HTTP是一个无状态的协议。如果HTTP客户端请求数据，那服务器端会及时响应，但是服务器不会记住客户端的状态，每个HTTP请求都是在一个时间会话中独立处理。HTTP无状态协议很难直接应用在媒体流传输上。Windows Media Service使用改进版本的HTTP协议，MS-WMSP协议作为微软媒体传输的基础协议。MS-WMSP使用标准的HTTP协议来传输数据和信息，同时也为此会话状态，有效的将HTTP协议转化成类似RTSP的传输协议。类似RTSP和Windows Media HTTP传统流媒体协议有两点比较重要：

服务器向客户端实时发送数据包，媒体流的码率在编码时被决定。例如：一个视频节目被编码成500Kbps的码流，那么传输到客户端的码率大约也是500kbps。

服务器只会发送部分未播放节目的数据包去填充客户端缓冲区。通常，客户端的缓存区是1秒到10秒之间。这就意味着，如果你暂停一个节目流10分钟，在这段时间内大约只有5秒钟的节目被下载到客户端。

2.2渐序性下载

另一种通常的互联网媒体传输形式是渐序性下载，它本质上和从网页服务器上下载一个文件差不多。大多数的播放器和媒体传输平台支持渐序性下载，渐序性来自于大多数播放器允许媒体文件回看，而后台同时也在下载节目。支持HTTP 1.1的客户端能够定位到未下载完整的文件位置。目前流行的视频分享网站包括：YouTube、Vimeo、Myspace、MSN 都支持渐序性下载。不像传统流媒体服务器很少能在一个时间段内够发送超过10秒媒体数据给客户端，HTTP网页服务器能够保证持续的节目数据传输直到整个文件下载完成。即使客户端在回看时暂停节目播放，节目数据依然会持续下载到浏览器的缓存中，保证用户能有良好的收看体验。这种方式也有它的问题，如果客户端找30秒内下载完成了10分钟的节目，而用户只观看了30秒钟的节目就退出观看，那就浪费了9分30秒的带宽资源。为了解决这个问题，微软IIS 7.0提出了一个名为“Bit Rate Throlling”的技术，它能够控制流媒体服务器的内容传输速率，以达到减少带宽浪费的目的。

2.3 HTTP为基础的流媒体自适应传输

HTTP为基础的流媒体自适应传输是一种混合型的传输方式，它的传输动作类似流媒体，但是实际上是基于HTTP渐序性下载。HTTP为基础的自适应流媒体传输的好处是使用了已有的HTTP协议而不是去开发一个新的传输协议。微软提出的Smooth Streaming和移动网络自适应码流传输都是HTTP为基础的自适应流媒体传输的应用实例，该技术能够实现持续的小数据的下载，而不是一个大文件的连续下载。在典型的HTTP为基础的自适应流媒体传输方案中，音视频节目被编码成许多小的数据片，这些小的数据片组成一个数据块，一个数据卡通常是2～4秒长。从编码技术角度，一个数据块正好就是一个GOP的大小，每个GOP里有一个关键帧，每个数据块或GOP的解码都是独立不依靠其他的数据块或GOP。

码流自适应技术有几个共同的技术特点，第一，它从同一个源产生多个不同码率的节目流以适应不同的带宽和不同的设备类型。第二.自适应分发文件以及码流传输的变化都是适应有效网络吞吐量和可用的CPU资源。第三：所有的操作对用户都是透明的，节目流的切换都在后台进行，用户很难注意到节目流的变化。同时，码流自适应技术运行特点也是相似的，当然也有几点关键不同点，相同点是所有的码流自适应技术都有几个相关的关键参考参数，例如：视频缓存区状态、网络有效吞吐量、CPU利用率以及丢帧后消耗的计算资源等，这些参数决定了何时去改变码流。不同厂家的在码流自适应技术一个关键的不同就在是否部署流服务器上。一种设计方案是由流服务器来实现不同码率节目的切换，而另一种则没有码流服务器，而是同时部署多个网页服务器或利用一台网页服务器来提供不同码率节目的传输，而用户端的设备通过监视终端CPU利用率、缓存区状态等参数以决定何时在不同的码率节目见切换。

 

自适应流媒体传输相对与传统流媒体传输具有以下几个优点：

（1）由于该技术方案能够充分利用广泛存在HTTP基础环境，它实施起来成本更低；

（2）它具备了更好的伸缩性和可达性，减少了最后一英里带来的问题；

（3）它能够让观众有更好的体验，而不需要内容提供商或运营商去猜测用那种码率传输更适合观众；

对用户而言它同样具有以下几个优点：

（1）快速播放以及拖动，因为播放或拖动节目都是在低码率下完成，等动作完成后客户端会主动切换到高码率上去；

（2）没有缓冲等待、没有链接中断、没用回看停顿；

（3）平滑的在不同码率节目间切换；

目前，不同的IT、软件已经互联网企业已经看到了未来互联网电视发展趋势，纷纷推出自己的解决方案，以下主要想介绍Apple、Microsoft、Adobe以及MPEG组织的互联网电视技术方案。

 

3．APPLE HLS

3.1.1 发展历史

Apple公司首次在2009年IOS 3.0中集成了HLS HTTP Live Streaming技术，截止到今天HLS是全球应用最广发的互联网电视传输技术协议，该技术被广泛应用到Apple公司产品终端和机顶盒中。在2010年9月1日，Steven Jobs报告中公开介绍了基于HLS的直播技术，同时宣布了APPLE TV 2。IPAD的成功很大程度上适合了用户使用IPAD看视频的需要。MeFeedia公司一向研究报告表明IPAD用户在线看视频时间长度是传统视频网站用户的三倍。

3.1.2 关键技术点

HLS主要基于TS的视频流或文件进行封装传输，HLS类似一个容器封装MPEG TS传输格式。TS是广播电视行业中采用的节目传输格式。HLS编解码采用MPEG-4或H.264，音频采用AAC。这样技术路线使得APPLE可以使用成熟工业标准，将其应用在互联网电视技术方案上几乎不需要改动，对现有标准兼容的越好，HLS便可以更快进入到产业链中。

 

HLS方案主要技术特点：

（1）节目源采用H.264/TS编码格式，可变码率；

使用流切片技术将一个完整的节目切成若干小片，通常是10秒每片，同时使用m3u或m3u8格式生成播放列表文件用来指导播放器如何播放文件切片；

（2）通过HTTP Server分发节目，同时提供合适的缓存。

HLS技术另外一个优势是能够实现动态自适应码率传输。相对于移动流媒体RTP传输技术，HLS能够根据终端用户带宽的可用性在终端而不是在前端视频服务上，实现对码率的切换。这种实现方式是为用户在无保障的网络上提供好的用户体验。

（3）索引文件说明了在同一个频道或文件中不同码率节目流的对应性；

（4）终端根据接收切变文件的时间长度来选择最合适的码率；

（5）每个切片文件最长10秒，所以接收设备可以自动适应码率变化；

开发基于HLS DRM客户端并不困难，Verimatrix,  Widevine, NDS, Latens与SecureMedia 一些DRM公司基于PC平台的DRM解决方案也可以适应HLS方案。如果进一步研究HLS中的DRM技术，会发现HLS只是描述了如何利用128位AES算法加扰HLS流，并没有说明如何从DRM 密钥服务器中获取密钥。这就说明DRM与HLS之间并不完全兼容。

3.1.4 优势

截至到2011年9月，APPLE已经出售了13亿台IPHONE，6千万台IPOD Touch，以及超过3千万台IPAD，因此HLS技术有着巨大的市场，特别是针对便携设备。HLS为不可靠的开放网络提供了一种有效的码率自适应方案。HLS使用成熟的H.264编解码技术，目前H.264解码芯片提供商有很多。HLS基于TS技术，使得它可以很容易集成到已有的数字电视系统中，许多IPTV DRM方案提供商能够提供相应的解决方案。

3.1.5 不足

自适应技术方案只限制在用户端，这种动态方法可能限制某些专业用户希望能够自己对特殊内容传输进行微调和控制；APPLE并没有支持主要浏览器集成HLS，缺乏插件使得利用Web TV收看HLS节目变得困难；HLS主要使用MPEG标准，兼容HLS技术的设备可能需要向MPEG LA支付一定的专利费。HLS中DRM加密采用是端到端整体加密实现，这样降低了系统的灵活性；目前，HLS只能提供一个音轨在一个视频流中。IOS 5能够提供可切换的音轨，但是音轨数量被限制在2个，而在Smooth Streaming或MPEG-DASH中则对音轨的数量没有限制。

3．2  Microsoft Smooth Streaming

3.2.1 发展历史

微软在1998年在Netshow Service和Windows Media Player 6.1中首次采用了根据客户端状态自适应节目传输码率的“stream thinning”的技术。该技术通过自动检测终端网络情况，自动减少帧率。在网络条件比较恶劣的情况下，客户端可能会终止整个视频的播放而只是播放声音。最早的多码率媒体流传输时在Microsoft 2000中，作为Windows Media Technology 4.0和Windows Media Service 4.1服务的一部分，和Windows Media Player 6.4一起发布的。在2002年，微软在Windows Media 9系列产品中引入了 “Intelligent Streaming”。Intelligent Streaming依然采用ASF封装格式，但是在该技术的设计上，它将带宽侦测、streaming thinning、MBR以及更好的图像处理结合起来。随着技术发展，微软在2009年发布Microsoft Smooth Streaming是Silverlight 3.0相关标准。Microsoft在它的技术方案中采用H.264与AAC编码方案，也能够支持微软自己提出的WMA与VC-1或者能够支持3GP封装支持的编码方案。

 

3.2.2关键技术点

IIS采用MPEG-4 Part14标准格式作为其文件存储格式以及传输封装格式。Smooth Streaming方案中定义每个文件块/GOP作为一个MPEG-4电影帧，并将其存储在一个联系的MP4文件中以利于系统读取。一个MP4文件编码成一个码率。当客户端从IIS网页服务器上请求一个特点时间片段的节目源时，服务器将动态联系的MP4文件中寻找合适的电视帧单元（BOX），并且将它作为一个独立的文件发送。换句话说，Smooth Streaming方案中文件块是在服务器端接收到客户端请求时产生的，在服务存储中视频内容是以一个完整的单一码率文件形式存在。

（1）Smooth Streaming流格式介绍

Smooth Streaming格式涉及两个部分，封装格式和硬盘存储格式。Smooth Streaming中视频作为一个单一码率文件完整的存储在硬盘中，在传输给客户端的时候会转换成许多小的文件数据块。封装格式是用来传输时使用，而文件格式用来描述文件在硬盘的存储格式。MP4允许文件以一系列片结构组织及存储，这就意味着Smooth Streaming封装格式是文件存储格式的子集。

（2）Smooth Streaming文件硬盘存储格式

MP4文件的基本单位是“BOX”。这些“BOX”中即包含数据也包含元数据。MP4支持在一个文件内容以不同的方式来组织数据和元数据。在大多数媒体场景中，将元数据放在负载数据之前对于播放器的读取时非要有用的，因为播放器可以在播放之前可以更多的知道负载数据信息。然而，不太可能在整个数据流前写入元数据。较少的元数据信息意味着小的数据包头，有利于更快的启动播放器。基于以上理由MP4 文件格式中允许存在一系列晓得元数据、负载数据对，而不是一个长的元数据/负载数据对。下图描述了在一个Smooth Streaming文件中文件组织格式：

 

从上图中我们能看到在一个外壳中，文件以文件元数据信息（moov）开始，但是负载带元实际包含在片BOX单元中，在这些BOX中又携带了准确的文件片元数据（moof）和媒体数据（mdat），格式以mfra索引BOX结束。

（3）Smooth Streaming文件封装格式

当一个播放器客户端向IIS服务器请求一个视频时间片段时，服务器会在MP4文件中寻找合适的文件片，并将其取出封装完成后传输给客户端。文件片经过封装后可以有效提高传输效率。下图描述了一个MP4文件片封装结构

 

微软在MP4 ISO媒体文件描述格式的基础上自定义了BOX组织数据结构和BOX信息。为了区分Smooth Streaming文件和标准的“vanilla”MP4文件格式，微软使用了新的文件扩展：*.ismv(视频和音频)和*.isma音频

（4）Smooth Streaming 播放

Smooth Streaming自适应播放的设计原理本质上是将一个长的视频文件切成许多小的文件片。为了从Web服务器中获取这些文件片，客户端播放器只需要按照连续的逻辑序列0001.vid 0002.vid 0003.vid…下载文件即可。

在Smooth Streaming的设计方案中，微软使用了更加复杂的设计。视频文件不需要被切成无数小的文件片，而只是在传输时按照文件片的方式传输，而这些文件片实际上来自MP4文件中的GOP片段。这样的设计需要在服务器端和客户端实现以下两点改变：

服务器必须能将URL转换成在MP4文件中的准确的偏移范围；

（5）客户端能够支持更加开放的请求格式；

客户端播放器首先从Smooth Streaming服务器上获取*.ismc客户端文件块索引文件文件。该文件告诉播放器节目内容的编码格式、码率、清晰度以及可用数据块列表。

在Smooth Streaming中客户端请求文件数据块的URL以以下方式描述：

http://video.foo.com/NBA.ism/Qualitylevels(400000)/Freaments(video=610275114)

在以上URL中出现的数字分别代表了编码码率和在一个单位时间段内（通常是100ns）片段开始位置的偏差值。在服务器端收到客户端请求后，Smooth Streaming在服务器文件块索引文件文件中查找码率，并寻找对应的.ismv .isma文件。然后基于tfra索引单元（BOX）找到相应片段（moof+mdat）和开始时间偏差值，读取相关的MP4文件封装后发送给客户端。这个部分的设计对于整个传输设计是至关重要的。客户端下载的内容会在网络中自动缓存，如果其他的客户端请求了同样的内容便会从缓存中获取这样就大大节省了服务端的压力。

3.2.3 优势

Smooth Streaming在一个码流中能够支持多声道和多个主题。这为用户提供了与收看数字广播想同的体验。相对于其他互联网电视方案而言，Smooth Streaming已经将DRM很好的集成到其中。虽然，微软也有自己的PlayReady解决方案，它也明确的支持其他的DRM厂家与Smooth Streaming的集成。在网页媒体领域，Smooth Streaming在高清直播中获得了很好的图像质量，与以flash技术为基础的视频网站相比，Silverlight能够根据客户端的解码能力去选择合适的节目码率进而保证节目的流畅。对于微软的互联网电视方案来说，这可能是一个优势也可能是一个劣势，微软互联网电视技术方案说明十分详细，使用了许多例子进行说明，这使得技术人员很容易理解该方案，但是可能会花很多时间进行部署。

3.2.4 不足

正如上文提到的，微软的互联网电视方案非常详细，所以部署起来很费时间，结果是该方案不如HLS那样容易被接受。尽管Smooth Streaming以Web媒体为目标，但是客户端必须嵌入Silverlight，及时是IE浏览器也必须安装额外的插件。像HLS一样，Smooth Streaming不能依靠网络中心服务器来管理带宽，这些工作必须依靠客户端设备。

3．3  Adobe HTTP Dynamic Streaming

3.3.1 发展历史

如果我们回看本世纪初开始整个互联网视频传播的发展历史，我们会发现Adobe毫无疑问是其中的主要贡献者，许多知名网站如：YouTube、Dailymotion、Hulu以及成百上千的视频网站都使用了Adobe的方案。然后，大多是视频采用的是.FLV格式（不是直播流媒体），无法支持DRM,也不支持码率自适应。Adobe Flash在1996年发布，根据Adobe公司的报告，在2010年全美98%的网页使用者使用Flash Player。然后第一个能够播放视频段的Flash payer是version 6.在2010年七月，Adobe发表了互联网电视方案，支持码率自适应机制，支持直播，支持Adobe自己的Flash Access DRM方案。

3.3.2 关键技术点

从技术角度来看，HDS方案与微软的Smooth Streaming十分相似，HDS系统主要由以下几个部分组成：

一个以XML为基础的索引文件.f4m

包含MPEG-4编码格式内容的片文件.f4f

包含切片文件说明信息的索引文件.f4x

HDS支持H.264以及VP6视频编码格式，AAC和MP3音频编码格式。.f4m 文件块索引文件文件包好一个bootstrap，它相对于MPEG-DASH的初始化段，这能够指示终端播放器从哪一个片开始解码。在文件块索引文件中，如果有多种码率可选，播放器能够根据内容回看效果选择最合适的码率。播放器是用ActionScript语言编写，能够运行在Flash或者Adobe AIR框架下。Adobe提供了一个参考视频播放器，称为Open Source Media Framework（OSMF），在互联网上已经有一些flash/javascript播放器基于这种方式编写，这些播放器基本上是完全定制化播放HDS视频流。对于内容保护而言，HDS唯一支持的DRM方案是其自身Adobe DRM系统，Flash Access服务器，Flash Access方案是一个很有特点的加扰系统，版权管理中有很灵活的控制权，它能够对保护层进行保护也能够对视频文件切片进行保护。

3.3.3 优势

Adobe成功在月在互联网早期发展过程中将其框架作为一种强制插件嵌入到网页中。同时，Flash插件到今天已经有能力自动更新，现在几乎所有的PC都能播放Adobe HDS码流。HDS在Adobe为VOD应用提供了丰富的文档，他们能够为开发送人提供一些参考源代码以支持对方开发有价值的第三方插件。

3.3.4 不足

Apple目前在Apple产品中不支持Flash。但是对于Android平板电脑和智能手机，Flash的支持非常依靠具体的Android版本，即使是特定Android版本，Flash支持也依赖硬件平台厂家。HDS只支持自己的DRM方案，从Adobe开放出来的文档中也很难看出Flash Access是如何工作的，尤其是直播应用。和Apple HLS一样，HDS码流目前只能提供一个音轨。在改进版的系统中对于点播节目能够提供可替换音轨，但是直播节目不具备这个功能。

3．4  MPEG-DASH

3.4.1 发展历史

2010年，3GPP和OIPF发布了自己的码率自适应方案，Adaptive HTTP Streaming（AHS, part of 3GPP R9）和HTTP Adaptive Streaming(HAS), 但是，这些协议没有兼容。MPEG-LA和ISO标准组织创立了横跨整个业界的HTTP Streaming协议小组：MPEG-DASH（Dynamic Adaptive Streaming over HTTP）,第一个DASH草稿在2011年2月发布。DASH技术目的是标准化HTTP Streaming技术以取代目前已经存在的不同厂家的技术方案，如：Microsoft Smooth Streaming、Apple HTTP Live Streaming。DASH工作组已经在产业界取得了一定的支持，但是目前Adobe和Apple并未明确表态支持DASH。对于DASH来说现在它不支持HTML5 传输的编码节目，这就意味着它可能采用H.264或是WebM编码方式。最后，DASH是否免费还不知晓，这可能会影响一些潜在用户，如Mozilla。所有的HTTP为基础的码流传输技术都包含两个功能模块，节目码流和文件块索引文件，在DASH方案中节目码流称之为媒体表示，而文件块索引文件称之为媒体描述，如下图所示。

 

3.4.2 关键技术点

下图描述了MPEG-DASH前端HTTP服务器和MPEG-DASH客户端之间的逻辑关系。节目内容首先存储在MPEG-DASH前端HTTP服务器上，随后使用HTTP协议进行传输。媒体内容在服务上存储方式由两个部分组成：第一：媒体内容描述Media Presentation Description (MPD)，其中包括内容的文件块索引文件文件、内容的变量信息、URL以及其他特点。第二：文件片段，它代表了该节目所有的节目数据块。

 

在播放节目内容时，MPEG-DASH客户端首先要获取MPD文件，MPD文件可是通过HTTP、email、广播或者其他方式传输。通过解析MPD文件，email客户端可以了解节目的时间信息、节目的可用性、节目类型、清晰度、最大与最小带宽，以及几种不同编码码率的节目流、DRM信息、节目位置以及与内容相关的其他信息。利用以上这些信息，MPEG-DASH客户端选择合适码率进行播放。在节目内容开始传输并开始缓冲时，客户端继续从服务器端获取节目片段，并检测网络带宽变化。通过对网络带宽的检测客户端可以选择接受多大码率的节目。在MPEG-DASH中只定义了MPD和文件片段的格式，并没有定义二者的封装格式以及客户端如何获取二者。

3.4.3 优势

从纯技术的观点，在所有的互联网电视方案中MPEG-DASH看起来像最好的选择，它采用了好的设计思想，同时保持了很好的兼容性。作为被ISO和MPEG-LA推动的标准，与其他软件或互联网公司设计的互联网电视方案，它的设计更好满足产业实际。Ultraviolet很好了反映了“buy once, play anywhere”的设计思想，只有很少数的消费者是Apple或Android的忠实支持者，大多数用户拥有多个不同类型和厂家的终端设备；

3.4.4 不足

从用户端看，非常少的播放器采用MPEG-DASH方案，而且MPEG-DASH方案仍然处在起草阶段；Apple和Disney公司没有参加Ultraviolet组织，Ultraviolet是对Apple产品的一种潜在威胁，它允许用户在其他不同的设备上观看同一个视频流。

 

总结

综上所述，对于哪种互联网电视方案是最好的，并没有一个明确的回答，所有的方案都有着优势和不足。现在很难预测哪一种互联网电视技术会在未来成为最终的赢家，就目前而言，由于Apple在全球取得的巨大成功，使得HLS方案在目前市场竞争中保持领先优势。当网络运营商在自有的IPTV专网中提供多屏服务时，视频服务的质量和视频数量是吸引用户的关键，而互联网电视对于想提供视频服务的新厂商提供了一种重要机会，新的竞争者不需要复杂网络基础环境就可以提供创新的服务。

 

参考文献：

[1] Lionel Bringuier, White Paper OTT Streaming – 2nd edition, http://www.anevia.com;

[2] Alex Zambelli , IIS Smooth Streaming Technical Overview, http://jmvm.vse.cz/wp-content/uploads/2011/05/t_IIS_Smooth_Streaming_Technical_Overview.pdf;

[3] I. Sodagar, The MPEG-DASH Standard for Multimedia Streaming Over the Internet, IEEE Multimedia, IEEE MultiMedia, October–December 2011, pp. 62–67.