浅谈HTTP Adaptive Streaming技术及其前景
关键词：OTT 流媒体 HTTP Adaptive Streaming
本文已发表于《世界宽带网络》2011.6 第18卷第5期 总200期
HTTP Adaptive Streaming（以下简称“HAS”）技术结合了传统的流媒体技术和HTTP渐进式下载播放的特点，以HTTP的方式向用户传送媒体内容，该技术的采用可以大大提升用户的媒体播放体验，同时该技术降低了头端服务器的技术复杂度。基于HTTP的传送方式提升了媒体内容在网络设备中的穿透能力，该技术目前已成为流媒体视频行业发展的趋势。
一、传统流媒体技术
近些年，互联网视频迅猛发展，视频内容的流量已占到了整个互联网流量的一半。谈到互联网视频就不得不提到流媒体技术，正是流媒体技术的不断发展促进了目前互联网视频的迅猛发展。
传统的媒体内容分发技术主要有两大类，一类是以RTSP/RTP(Real Time Streaming Protocol/Real Time Transfer Protocol)为代表的面向连接的流媒体技术，另一类则是目前主流视频网站采用的无连接的HTTP渐进式下载。
1.RTSP/RTP的流媒体方案
RTSP是一种传统的流媒体控制协议，其具有状态性的特点意味着从一个客户端开始连接至服务端一直到连接中断的整个过程，服务端会一直监听客户端的状态。客户端通过RTSP协议向服务器传达控制命令，如播放、暂停或中断等。
RTP/RTCP(Real Time Transfer Control Protocol)是端对端基于组播的应用层协议。其中，RTP用于数据传输，RTCP用于统计、管理和控制RTP传输，两者协同工作，能够显著提高网络实时数据的传输效率。
基于此架构的流媒体技术方案，服务端和客户端之间建立连接之后，服务器开始持续不断地发送媒体数据包，媒体数据包采用RTP进行封装，客户端控制信息通过RTSP信息包以UDP或TCP的方式传送。
另外，类似的流媒体协议还包括了Adobe的RTMP(Real Time Messaging Protocol)以及Real公司的RTSP over RDT(Real Data Transport Protocol)，本文就不在此对这些流媒体协议逐一进行介绍了。
2.HTTP渐进式下载
HTTP渐进式下载技术与有状态的RTSP/RTP技术相比，采用了无状态的HTTP协议。当HTTP客户端向前端请求数据时，服务端将请求的数据下发给客户端，但是服务端并不会记录客户端的状态，每次HTTP请求都是一个一次性独立的会话。
渐进式下载的功能目前主流的终端播放器均支持，如Adobe的Flash、微软的Silverlight以及Windows Media Player。所谓的渐进式下载，即终端播放器可以在整个媒体文件被下载完成之前即可开始媒体的播放，客户端及服务端如果均支持HTTP1.1，终端还可从没下载完成的部分中任意选取一个时间点开始播放。
目前，主流的视频网站均采用了HTTP渐进式下载的方式来实现流媒体的分发，如优酷网、土豆网等等。
3.方案对比
作为最简单和原始的流媒体解决方案，HTTP渐进式下载尤其显著的优点在于它仅需要维护一个标准的Web服务器，其安装和维护的工作量和复杂性比起专门的流媒体服务器来说要简单和容易得多。
然而，其缺点和不足也很明显。首先是带宽容易浪费。当一个用户在开始下载观看一个内容之后选择停止观看，那么已经下载完成的内容则是对带宽资源的一种浪费。其次，基于HTTP的渐进式下载仅仅适用于点播内容，而不支持直播内容（应该可以支持直播？）。最后，此方式缺乏灵活的会话控制功能和智能的流量调节机制。
而基于RTSP/RTP的流媒体系统专门针对大规模流媒体直播和点播等应用而设计，需要专门的流媒体服务器支持，与HTTP渐进下载相比主要具有如下优势。
-
流媒体播放的实时性。与渐进下载客户端需要先缓冲一定数量媒体数据才能开始播放不同，基于RTSP/RTP的流媒体客户端几乎在接收到第一帧媒体数据的同时就可以启动播放。
-
支持进度条搜索、快进、快退等高级VCR控制功能。
-
平滑、流畅的音视频播放体验。在基于RTSP的流媒体会话期间，客户端与服务器之间始终保持会话联系，服务器能够对来自客户端的反馈信息动态做出响应。当因网络拥塞等原因导致可用带宽不足时，服务器可通过适当降低帧率等方式来智能调整发送速率。
-
支持大规模用户扩展。普通的Web服务器主要针对大量小的HTML文件下载而进行优化，在传输大容量媒体文件方面缺少性能优势。而专业的流媒体服务器在大容量媒体文件硬盘读取、内存缓冲和网络发送等方面进行了优化，可支持大规模用户接入。
-
内容版权保护。在渐进下载模式中，下载后的文件缓存在客户端硬盘的临时目录中，用户可将其拷贝至其他位置供以后再次播放。而在基于RTSP/RTP的流媒体系统中，客户端只在内存中维持一个较小的解码缓冲区，播放后的媒体数据随时清除，用户不容易截取和拷贝。此外还可利用DRM等版权保护系统进行加密处理。
尽管如此，基于RTSP/RTP的流媒体系统在实际的应用部署中仍然遇到了不少问题，主要体现在：
-
与Web服务器相比，流媒体服务器的安装、配置和维护都较为复杂，特别是对于已经建有CDN(内容分发网络)等基础设施的运营商来说，重新安装配置支持RTSP/RTP的流媒体服务器工作量很大；
-
RTSP/RTP协议栈的逻辑实现较为复杂，与HTTP相比支持RTSP/RTP的客户端软硬件实现难度较大，特别是对于嵌入式终端来说；
-
RTSP协议使用的网络端口号(554)可能被部分用户网络中的防火墙和NAT等封堵，导致无法使用。虽然有些流媒体服务器可通过隧道方式将RTSP配置在HTTP的80端口上承载，但实际部署起来并不是特别方便。
二、HTTP码率自适应
上一节中我们谈到了基于RTSP/RTP的流媒体技术以及基于HTTP的渐进式下载，但是我们可以清楚看到两种方案均存在着各自的缺点。
这时HAS技术应运而生，它融合了传统RTSP/RTP流媒体技术以及基于HTTP渐进式下载技术的优点，具有高效、可扩展以及兼容性强的特点。图2为HAS技术的实现原理。
HAS技术是一种混合的媒体分发方式，给用户的体验是流的方式，但是实际上与HTTP渐进式下载方式一样采用HTTP协议完成了内容的下载分发，但这些媒体内容都被切割成了一系列的媒体分块进行传输。
HAS技术的一个关键就是媒体数据的切割分块，每个分块的时间长度相同，一般为2～10秒。在视频编码层，这意味着每个分块都由若干个完整的视频GOP组成(每个分块都有一个关键I帧)，以此保证每个分块都与过去及将来的媒体分块无关联。
如图3所示，媒体分块存储在HTTP Web服务器中，客户端以线性的方式向Web服务器请求媒体分块，并以传统的HTTP方式进行媒体分块的下载，当媒体分块下载至客户端时，客户端按照顺序播放这一系列媒体分块。因为这些媒体分块按照约定的规则进行编码，各个媒体分块之间没有内容的重叠或不连续，对于用户来说，则看到了一个无缝平滑的播放效果。
若一份内容在编码输出时已提供了多种码率，则内容切片模块会将其切割成多种码率的媒体分块。因为Web服务器传输数据是尽可能地利用网络带宽来进行内容的下载，没有流量的控制机制，客户端可以很容易地检测到Web服务器到客户端的可用网络带宽，从而决定下载更大或更小的媒体分块，实现码率的自适应。
从图4我们可以看出，HAS的关键技术主要由两大部分，一是内容的准备，包括了支持多屏的转码平台以及媒体的分割切片模块，其次是内容的分发，包括了基于HTTP的内容源服务器以及面向终端的内容分发网络，完成并发流数量的放大功能。
三、HAS技术特点分析
1.采用HAS的优势
HAS与其他基于HTTP传输媒体的方式一样，和传统的流媒体分发技术相比，具有以下优势：
-
Web服务器更容易部署，因为HAS技术采用了通用的HTTP协议，传统的HTTP缓存/代理、防火墙等网络设备可以完美兼容；
-
提供了更好的兼容性和到达率，可根据最后接入网的带宽大小动态地调整码率，实现内容的分发；
-
对于用户来说体验更好，且不需要业务提供者去考虑收看用户的带宽。
HAS除了上述优势之外，还有以前任何技术均不具备的特点，具体如下：
-
用户等待的时间更短，可以快速实现播放——客户端初始化默认选择低码率，开始播放后逐步向高码率进行切换，因此，其服务质量是在可用带宽范围之内不断被进行调整和优化；
-
不需要大的缓存，不间断地播放，没有抖动的平滑视频播放体验；
-
基于网络状况和CPU解码能力的无缝码率切换；
-
客户端不需要下载超过它实际消耗的内容。
综上所述，相对于传统的流媒体技术，它能够提供更好的服务质量，因为它可以使用整个可用的带宽，而非自适应流技术则是强制客户端选择一个低于可用带宽的固定比特率。可以预见，HAS技术在不久的将来将得到广泛的部署及应用。
2.需要面对的问题
上一节我们谈到了HAS的优势及技术实现原理，似乎HAS的实现非常简单，首先在内容准备上提供多个码率的媒体文件，并提供一个索引文件，其中记录了各个码率文件的关系及特性，接下来终端根据初始的带宽情况选择一个码率的媒体文件进行顺序播放，期间根据网络情况以及CPU的负载调整码率。
但是HAS技术方案具体部署实施时有许多问题需要去明确，如果这些问题没有得到很好的解决，则无法提供最佳的用户体验。
-
采用几个码流？
-
码流的分辨率？
-
关键帧间隔？
-
VBR or CBR？
-
音频参数的设置？
四、HAS企业方案及技术标准
目前，HAS技术的实现方式从标准的类型来看主要有两大类：一类是企业方案，即提供了整体的技术解决方案，如Apple Live Streaming技术、Microsoft Smooth Streaming技术、Adobe Dynamic Streaming技术；一类则是一些国际标准组制定的技术标准，如OIPF的HTTP Adaptive Streaming、MPEG的DASH(Dynamic Adaptive Streaming over HTTP)、IETF的草案（由Apple公司提议的草案）。
1.OIPF
OPEN IPTV Forum在其定义的OIPF技术规范中对码率自适应技术进行了界定，规范中对如何实现HTTP码流自适应的理论进行了细化及扩展，明确了如何使用及使用的范围。该标准以3GPP的Adaptive HTTP Streaming技术规范为基础进行相关的扩展，增加了对MEPG-2 TS格式的支持。
OIPF的码率自适应标准中对终端下载的索引文件进行了定义，OIPF中将索引文件命名为MPD(Media Present Description)文件，采用XML格式进行组织。
同时OIPF标准规定了媒体的封装格式为TS和MP4，并且对分片的一些细节进行了界定，如同一内容的不同码率的文件必须使用同样的媒体封装格式，但是编码的Profile可以不同。
该标准对直播应用场景以及快进、快退、定位等操作均进行了定义。
2.MPEG
近来，MPEG标准发布了一项关于HTTP Streaming的标准DASH，见图5。
DASH标准对目前出现的HAS技术框架进行了总结归纳，对背景、目的以及使用场景进行了介绍。该标准中定义了一系列的使用场景，如3D Video、互动3D、动态码率自适应、Peer-2-Peer以及多画面电视，同时还对如何与内容保护技术结合进行了定义。
DASH标准的制定主要为了解决以下问题：
-
更为有效地将MPEG的媒体通过HTTP协议，以自适应、渐进式、下载或流的方式进行内容分发；
-
支持直播业务；
-
更为有效地利用传统的基于HTTP的CDN网络、代理Server或防火墙等网络基础部件；
-
支持与内容保护系统的结合，完成对内容的保护。
总的来说，DASH对采用HTTP传输MPEG媒体涉及到的各方面提出了一系列的技术要求，包括了媒体内容格式、传输方式、MPD文件、业务控制、自适应以及媒体保护等。
3.Apple HTTP Live Streaming（IETF）
HTTP Live Streaming是Apple公司的HAS整体解决方案，该方案设计的目标主要是通过普通的Web服务器将直播内容或点播内容推送至Apple的终端设备，如iPhone、iPad以及苹果的台式机。Apple公司的技术规范现已提交至IETF组织讨论，目前还在标准的草案阶段。
HTTP Live Streaming由三部分组成：服务器组件、分发组件和客户端。首先，编码器接收音视频输入，并采用H.264编码技术，输出MPEG-2 TS流，然后利用切片软件按设定的时间间隔对TS码流进行切割并保存为一个个TS文件。这些TS文件部署在Web服务器上，切片软件同时还创建了包含这些TS文件相关信息的索引文件。索引文件的URL在Web服务器上发布，客户端读取索引文件，然后按顺序向服务器请求媒体文件并无停顿地显示它们。一个简单的HTTP Live媒体流配置如图6所示。
在苹果的动态码率自适应体系中，索引文件被保存为.M3U8文件，这是保存MP3播放列表的.M3U格式的一种扩展。HTTP Live Streaming支持实时广播会话和视频点播会话两种应用场景。
对于实时会话来说，当新的媒体文件被创建时，索引文件也会随之更新，旧的索引文件通常会被删除。更新的索引文件会在连续流中显示一个移动的窗口，这种类型的会话适合连续的直播内容。对于视频点播会话，媒体文件在整个会话周期内都是固定不变的。索引文件是静态的，只需在媒体开始播放前获取一次，其包含了所有媒体文件的完整列表。
目前，HTTP Live Streaming没有考虑对DRM的完整支持（？），但它支持内容的加密，通过16位密钥的AES-128加密算法对内容加密，HTTP Live Streaming中仅对如何通过URI获取密钥进行了粗略的定义。
4.Microsoft Smooth Streaming
Smooth Streaming是微软提供的一套HAS解决方案，基于Microsoft的头端Web服务IIS 7以及其终端的Silverlight技术。微软的Smooth Streaming选择了MPEG-4格式为媒体封装格式，Smooth Streaming将每个分片都用MPEG-4封装成一个MPEG-4的Fragment，但是存储为一个完整连续的MP4文件，事实上媒体仅仅是做了虚拟的分片。当终端的播放URL的请求上来时，头端服务器需要准确地分析URL请求，并将其转化为精准的偏离量，从而找到对应的媒体数据块分发给终端。
之所以选择MP4作为媒体文件格式，主要是因为MP4相比于ASF是一个轻量级的容器，更容易使用.NET进行管理和控制，同时MP4是基于广泛应用的ISO Base Media文件格式规范，最重要的一点是MP4设计之初就考虑支持在一个文件内实现媒体内容负荷的分片。微软Smooth Streaming存储媒体格式、传输媒体格式分别见图7、图8所示。
从图8我们可以很清楚地看出，Smooth Streaming采用的是一种虚拟切片的技术，微软的HTTP码率自适应技术并没有真实地将媒体文件进行切片，每个码率对应的内容存储成了一个完整长度的文件，在实际播放过程中，根据终端的请求将每个Fragment独立分发给终端。
Smooth Streaming终端基于Silverlight进行实现，Silverlight可完成MPEG-4文件格式的解析、HTTP下载以及码率的切换。同时微软将这些功能以.NET代码的形式提供给开发者调用，开发者可对播放器的效果进行优化及调整。播放器的开发工作中最为复杂的模块是码率的切换模块，何时切换以及如何切换是此模块的核心功能，也是技术难点，如果想给用户最佳的体验，必须考虑以下问题。
-
当用户有足够的带宽但是CPU解码能力不足时该如何处理？
-
当视频播放被用户暂停或隐藏在背后时该如何处理？
-
当最佳的视频质量的分辨率超出了屏幕本身的分辨率时该如何处理？
-
下载播发的Buffer窗口该设置为多大？
-
当在播放过程中需要插入新的媒体内容如插播一段广告时该如何保证无缝的切换？
5.Adobe HTTP Dynamic Streaming
Adobe公司的传统流媒体解决方案RTMP+FLV的组合，在互联网视频行业得到了广泛的应用。针对动态码率自适应的需求，Adobe公司首先在其传统的解决方案上实现了码率自适应，但随后不久Adobe公司也推出了基于HTTP的码率自适应解决方案HTTP Dynamic Streaming，见图9。
Adobe HTTP Dynamic Streaming包含了多个部件来完成内容的准备工作，并通过HTTP将内容传送给终端的Flash Player。
内容准备模块包括了面向VOD和面向Live直播的模块，VOD打包模块将媒体文件分片，并以F4F的格式存储，Live直播打包模块将直播流实时地写入到F4V文件当中。
HTTP源模块是标准的Web Server，存储了F4F文件和媒体对应的F4M格式的索引文件，索引文件中包含了编码、分辨率以及码率等参数信息。
6.分析及小结
通过研究各种标准组提出的技术规范以及微软、苹果等公司的企业技术方案，我们可以看出基于HTTP的码率自适应的实现原理是类似的，主要的区别在于媒体文件格式以及索引文件格式的不同，如表所示。 在这里我们谈了许多HAS的优势，但是目前的技术体系还有许多方面有待完善及改进。
首先，上述技术体系都是基于Client驱动的模式，依靠Client对网络状况及其自身硬件平台的能力情况进行判断，通过解析索引描述文件，最终从头端Server中以主动“拉取”的形式获取内容。在直播应用中，终端是需要频繁不断地更新描述文件来获取新的内容的相关信息。如采用Server驱动的模式，则不需要对描述文件进行频繁地更新，Server不断获取到最新的内容，并且连续不断地以“推送”的方式向终端发送媒体数据，比较适应于对实时性要求较高的直播应用。
其次，上述HAS技术体系缺乏质量的监测与控制机制。例如，当一个用户在观看直播频道时进行频道切换，当前时间的GOP以及播放器需要的初始化信息需要尽快传送到终端进行播放，但是目前的HAS技术体系中没有对重要的HTTP包进行加速传输的机制。
五、展望未来
随着互联网技术的快速推进，利用互联网传输渠道提供视频服务已成为趋势。传统的广电运营商、新兴的视频网站、互联网巨头、彩电厂商以及消费电子类设备商纷纷涌入。所有的参与者都在积极打造各自的新媒体服务平台，以OTT的形式将内容分发至电视屏、PC屏以及手机屏。