论文部分内容阅读
摘要 随着信息技术的发展，富媒体越来越流行，相应地给运营商带来了技术和运营等多个方面的挑战。这种挑战主要表现在三个方面：内容是受管理还是不受管理?如何有效地处理多种不同的内容格式?如何应对富媒体对系统带来的冲击和影响?
本文主要从编解码器系统和自适应流媒体技术方案这两个方面来介绍相应的解决方案。本文详细地从发展背景、技术细节、主流方案对比、开放标准及发展趋势等几个方面介绍了自适应流媒体技术。限于篇幅，本文没有对编解码器系统进行深入展开，而是就富媒体的挑战探讨了针对性的措施。不过，需要要注意的是，自适应流媒体方案往往建立在高效的编解码系统之上。
富媒体带来的挑战
媒体的发展是从早期单一媒体发展到多媒体，再到如今的富媒体。虽然富媒体能够为用户提供各种各样、功能强大的互动体验，但是，富媒体无论是对内容提供商还是对网络运营商都带来了各种各样的挑战。下面首先来看一下媒体交付领域的混沌景象(见图1)。
图1描述了在媒体交付领域交错复杂的情形。内容提供商包括了媒体公司、出版商和各种企业级的应用；媒体交付网络则包括卫星、有线电视网络、互联网、电信网络(xDSL)、无线网络和企业私有网络等；而媒体消费的种类就更多了：传统电视、互联网电视、个人电脑、(智能)手机、平板电脑、Kiosk和智能电器等。哦，别忘了在内容提供商和网络提供商之间的重要玩家——广告商，它可是广大用户对OTY内容既爱又恨的根源，用户在享受免费媒体内容的时候，不得不承受各种形式广告的“骚扰”。
根据统计，运营商网络中的视频流量按照不同的类型所占的比例如表1所示。
由于OTY内容对于绝大多数的运营商而言是一种负资产，或者被认为是一种管道的泄露(至少在目前是这种情形)，因此如何在避免网络通信管道泄漏的同时推送更多的节目内容是很多运营商迫切希望解决的问题。除此之外，富媒体的流行对运营商还带来了技术和运营方面的各种挑战，下面我们重点介绍这三种挑战。
1 内容是受管理还是不受管理?
为了能够增加业务营运收入，内容提供商和网络运营商都希望能够有效地对内容进行管理，包括版权管理(DRM)、访问控制(CA)以及各种加密措施等。用户访问受管理的内容，往往是需要交费的，换句话说，受管理的内容就等于业务收入。
但是，在另外一方面，存在各种各样的内容商或个人用户，希望能够直接把内容提供给或共享给(其他)用户。他们不希望受运营商的管理，希望其内容能够自由流通。这方面最典型的例子就是Youtube业务。当然，内容提供商(者)可以通过诸如广告赞助的方式获得一部分的资助，而对于网络运营商而言，OTY内容对它们业务的威胁要远远大于其收益(至少在目前是这样的)。这里的威胁主要有以下几方面：
>广告业务收入的流失：由于内容提供商可以和用户自己面对面地沟通，因此就可以跳过网络运营商，广告商也就不用再理会网络运营商了。
>通过自身网络承载的OTT业务对其主要的收费业务造成冲击：最好的例子是Netflix业务，短短几年，Netflix就成为了北美最大的视频业务运营商，其注册用户数超过了北美最大的有线电视运营商Comcast。
>费用的增加：由于网络流量的增加，主要是基于视频的富媒体业务的增加，网络运营商需要为此投入大量的资金和人力来升级其网络基础设施以满足新业务的需要。网络运营商如果仅仅是收取带宽的费用，显然是不够的，尤其是对于有线宽带系统来说。
综上所述，不受管理的内容对运营商而言，其实只是一种费用。
2 不同的节目格式对业务质量的影响
视频节目的来源和格式有多种，例如MPEG2、H.264、MPEG 4、RTSP和HTTP 1.0视频等。另外，用户可以
用多种消费电子设备对媒体内容进行消费，这些设备类型包括各种智能手机、平板电脑、机顶盒、电视机等。
造成节目格式不同的原因有很多。例如，由于历史发展的原因，老的节目内容的格式(如MPEG-2SD／HD)和新的节目格式(如H.264SD／HD)不同。由于牵涉到版权管理和转码费用等问题，不是所有的运营商都愿意把传统格式的节目内容更新到最新的节目格式。另外，由于编码效率的差异，新的节目格式使用6～8M的带宽就能为用户提供高清H.264的节目，而在这种带宽条件下，老节目的效果只能是标清。因此，用户的体验显然是要打折扣的，而也没有人希望从内容提供商处获取质量很差的内容。
另外，别忘了不同格式对存储空间的影响，想想模拟录像带作为存储媒介的年代，太可怕了!因此，为了能够很好地支持基于富媒体的应用，采用高效、灵活的编码系统是必要的。
3 系统演变和融合的需要
早期的视频业务主要是线性、广播式的业务，因此网络基础设施也围绕着广播模式而建立。但是，富媒体更多的是以非线性、互动应用为主，是以数据和IT托管的运营环境为中心而构建的，因此视频业务的基础设施需要从以广播中心向以数据中心进行演变，并采用新的拓扑结构。
综上所述，为了应对富媒体带来的挑战，运营商需要重点关注的细分领域如下：
视频优化：重点是质量、带宽、存储和交互性。
网络优化：涉及流量管理、数据包检测服务质量、SLA等。
下面，我们重点从编解码器和自适应流媒体技术这两方面来探讨运营商如何应对“大文件、细管道”的问题。
采用先进编解码器的解决方案
如何才能在现有的网络基础上(“细管道”)“挤进”更多的节目内容或新业务(“大文件”)?一个很明显的解决方案就是采用先进的编解码器方案。我们的目标是要能够以最低的带宽获得最多的节目内容(或最高质量内容)，那么，该如何选择编解码器系统?下面就针对此罗列了一些关键性的需求和指标。
首先要做的是对内容的管理和优化。
>编码器方案应该是一个多用途的编码平台，要求能够在线性和视频点播应用之间进行动态切换，而且能够支持动态的“换码”(transcoding)应用。
>编解码器方案要能够与其他系统组件进行无缝集成，因此要求提供API的支持、易于自定义工作流、避免私有、专门的和单用途的系统方案。
>具有动态的适应性，支持自适应流媒体方案(下面有重点介绍)，能够建立量化的质量指标，并可对响应系统进行智能性的设置。
其次是要把不同的内容格式进行规整，能达到对视频资产进行优化管理的目标。
>从单一输入获得多重输出，即针对同一个节目内容，一次编码过程可以得到多种不同质量和码率的版 本。同时生成多种版本的资产，一方面可以应对不同的用户设备使用不同的接入技术对节目内容的访问，同时也可以增加资产的回报率。
>对内容格式进行规整，可以减少格式的种类。这一方面可以减轻存储负担，另一方面还可以减少需要保存的内容资产数量。如果把进行版权管理、加密和水印等保护措施的费用算进去，减少格式种类，是最直接了当的节省费用的方法。
>动态转码，即根据用户的需要进行转码。这样做的好处是一方面可以保持原有的授权，另一方面，还可以加强SLA性能，实现更低的延迟。
再有，就是要进行系统的融合，目标是以更低的成本进行统一的网络运营。
>发展以数据为中心的拓扑结构，通过工作流程、存储、网络、数据、客户关系管理和SLA等进行API的规范标准化，这样就可以便于业务在未来进行扩展和升级。
>开发统一的管理门户网站，为用户提供单点登录等功能，并提升用户的服务体验。
>优化工作流程，争取实现实时智能和反馈驱动的流程。
自适应流媒体技术
互联网一直处于不断地发展与演变之中。早期，网页页面虽然是纯粹由文字构成，但是图像很快就被纳入页面之中，并成为不可或缺的元素；进而是移动图片的出现，其形式主要是“动画GIF”；而真正全面支持视频内容则是最近几年的事情。
如今，视频播放在网络上可谓无处不在，可是要想获得流畅的播放体验并不总是如人所愿的，用户总会碰到这样或那样的问题：启动时间太长、无法检索并定位到任意的视频播放点、当视频重新缓冲时常常造成视频播放的中断等。好在在过去几年里，出现了一些新的视频交付技术，能够有效地解决这些问题，本文着重介绍其中之一的“自适应流媒体技术”。
1 流媒体技术发展背景
要在互联网上进行通信，就需要使用互联网协议(IP)，它通常是和传输控制协议(TCP)一起工作。IP协议负责把数据包通过互联网交付给请求的主机；TCP则保证所有的数据包能够按照正确的顺序无损地到达接收方。当然如果有必要的话，还需要重新排序数据包或要求重新传输丢失的数据包。
在互联网上保证文件的可靠传输是至关重要的，但要实现这些差错纠正功能也是需要付出代价的。TCP协议拒绝提供下一个数据包之外的任何东西，即使其他的数据包已经到达用户设备处并在缓冲区中处于等待状态(例如，一种可能的情形是当TCP正在等待一个重传数据包的到来)。虽然这种机制对于文件下载是很理想的，但是对于视频和音频下载播放的情形就不太适用了：因为在音视频播放过程中，通常是倾向于跳过缺失的数据包，这虽然会造成短暂的声音或视觉方面的抖动现象，但总比播放处于中止状态，一直等到丢失的数据包重新被传送过来要好很多。
为此，早先的流媒体传输协议，如实时传输协议(RTP)就没有选择使用TCP的纠错功能，而是选择使用了用户数据包协议(UDP)。UDP只过滤掉受损的数据包，但并不试图进行任何的差错校正。RTP协议仍然是目前最流行的音频和视频流传输协议之一，特别是在IP电话(VoIP)和视频通信等应用方面。但是，由于它缺乏对差错的纠正能力，因此RTP主要应用于受管理的内部网络。此外，大多数网络用户和互联网的防火墙通常都被配置成不允许UDP流量，换句话说，也不支持RTP业务流量。
超文本传输协议HTTP被广泛应用于互联网，并几乎服务于每个网站，而且绝大多数的防火墙都支持HTYP协议，虽然有时需要通过代理服务器来完成。因此，HTYP是一种非常具有吸引力的协议，它可以用于向广大的用户交付各种内容，当然也包括视频在内。通过HTFP交付视频最简单的方式，就是被称为HTTP下载的方式：多媒体文件被当成正常文件进行处理，并在互联网上进行传输，它同时还具备TCP的纠错能力。一旦文件完全下载后，就可以对文件进行播放——通常是在一个独立的播放器中进行的，当然也可以通过浏览器插件的方式进行播放。尽管该技术方案能够保证以最优的质量进行完全无缝地回放，但是也有缺点，就是用户需要耐心的等待，直到该文件完全下载之后才能进行播放操作。
另外一种用户体验更好的方法是预先准备好多媒体播放所需要的信息，用户可以边下载边播放。其具体方法是把所有需要开始播放的信息都挪到文件的开始处，这样智能客户端一旦下载了文件的开始部分，就有了播放所需要的所有信息，这样就可以马上开始播放，即使文件仍然处于下载的过程中!而且，这种方案对于服务器端没有特别的要求——仍然只需提供正常的下载文件。这种技术被称为渐进式下载。显然，下载速度要快到足以超过播放的速度，否则就需要对媒体内容进行重新缓冲，而如前所说，重新缓冲往往会造成播放中断，甚至需要重新启动播放过程等。另外，在这种情况下，用户搜寻任意播放时间点的能力是被降低的：只可能搜寻已经下载的部分。
当然，这种限制很快地就被一种更加聪明的方案所克服，新方案采用了一种更聪明的服务器，它能够理解多媒体文件的内部结构。在这种“伪”HTTP流传输方案中，客户端可以请求下载某个特定时间间隔的文件，因此在无需下载整部电影的情况下，就可以搜寻你所最喜爱的场景。然而，一旦客户端开始下载，它仍然需要尽可能快地下载(如同所有的HTTP下载情形)，如果你不准备观看整部视频时，这种方案会造成大量的带宽浪费。对这种方案的改进方法包括限制客户端或服务器的下载速度，使其能够“刚刚足够快”。但这种方案仍然存在一些问题，限于篇幅，我们不在这里赘述。
上述的技术方案都使用单一的“对话”来传输所有需要的媒体数据。当用户处于移动状态时，这就会有问题：例如，当某个智能手机超出了一个Wi-Fi的热点范围，它可以自动切换到一个蜂窝数据连接(如UMTS和EDGE和GPRS等)。然而，这种“漫游”会导致所有的活动会话中断，因此需要重新启动所有的会话连接。最重要的是，新的蜂窝连接很可能只能提供较少的带宽，而且该带宽很可能太低，以至无法继续支持用户在Wi-Fi热点中所使用的较高的视频比特率。
至此，自适应流媒体传输方案就应运而生了。
2 自适应流媒体技术方案
自适应流媒体方案一方面结合了上述诸多协议的优点，另外一方面努力摈弃了原有方案固有的一些缺点。虽然自适应流媒体技术可以运行在各种各样的协议之上，但它们通常是运行在HTTP协议之上，因此可以不费事地通过大多数的防火墙。使用HTTP还有其他优点，例如，缓存功能是建立在该协议核心之上的：每个HTTP对象都包含一个标签(tag)，它指定了该对象的有效时间，如果在这个时间跨度内被再次请求的话，那 么可以直接使用保存的副本而不用去麻烦原始服务器了。这样就可以减轻原始服务器的负载，因为系统自动把负载分摊给了边缘服务器(代理服务器或专门的缓存服务器)。
图2是负载分摊的示意图。初始请求将被转发到源服务器，一旦响应被检索到，它被存储在一个边缘缓存服务器中并传递给请求客户端。针对该对象的所有后续请求都将由该高速缓存区服务。一旦该对象不再有效(由原始服务器指定时间间隔)的话，它就从高速缓存中被删除。注意，即使对象有效，也有可能被高速缓存管理应用程序删除以便腾出更多的空间给热门的对象。
在服务器端，使用HTTP的另外一个好处是：这是一个无状态的协议。在一个无状态的协议中，服务器不用存储任何有关客户端或其请求的持久性信息，换句话说，一旦请求被处理，那么服务器就被重置到其原始状态(如果需要一个持久性的存储空间，那么就需要在HTTP之上进行处理，服务器通常使用一个数据库来存储持久信息)。该特点非常利于负载平衡：因为每个请求都可以由任何可用的服务器进行处理，而不需要跟踪是哪个服务器“拥有”哪些特定的客户端。
从服务器的角度来看，自适应流媒体技术其背后的基本原理相当简单：为客户端提供一个网址(URL)表，每个URL指向同一个内容的特定质量版本(如图3中的行)的特定时间间隔(如图3中的列)的视频片段，具体如图3所示。所有的智能性都是在客户端实现的，服务器可以是任何和HTTP兼容的设备，只要能服务常规的文件。
媒体文件被创建成多种质量版本的媒体流，在这里由不同的行代表；同时，这些不同质量的媒体流也被切成不同间隔的时间段(这里由不同的列代表)，并且每个不同质量版本的媒体流的时间间隔是同步的。每个单独分割的块都可以被客户端单独访问到。本示例使用的是固定大小的块，但在实际应用中可以大小不一样。
一旦客户端下载了URL表格，就需要利用客户端系统的信息来选择合适的URL，以便获取下一个内容块。显然，客户端应该从第一个时间间隔的内容块开始播放，但问题是该选用哪个质量版本的内容?通常，客户端都是从最低可用质量的版本开始，这将提供最快速的启动时间。在第一个内容块的下载过程中，系统能够估计可用的网络带宽信息：举例来说，第一个内容块的大小为400KB，而其下载时间为1.5秒，那么可以估算出网络带宽大概为2Mbps。随后，客户端通常就切换到在网络带宽可用范围之内的最高质量的内容版本。另外，搜寻节目内容的一个任意播放点也是可能的：客户端可以计算出相应的时间间隔，并马上请求该部分的内容块。
当然，具体的实现方案可以使用更多的指标而不仅仅是带宽。例如，客户端可以检测目前播出的视频分辨率，这样嵌入在Web页面中的一个微型／缩略图视频播放器就可以下载低分辨率的视频版本，即使当前的网络带宽可以支持更好的视频质量，也只有当处于全屏播放模式时，才切换到高清版本。客户端也可以把可用的CPU能力(或硬件支持)考虑进去，这样即使网络带宽支持更高的比特率，但由于硬件能力的限制，只能采用较低的视频版本，从而可以消除视频播放卡顿的现象。
为了实现码流的无缝切换和播放，对各个视频分块就有一些明确的要求。由于客户可以选择任意质量的任意一个分块，因此各个分块就必须是完全独立的。现代视频编码算法都使用“帧间压缩”算法：需要使用先前的视频帧来构建当前帧，并只发送这些视频帧之间的差异(从而达到压缩空间和时间上的冗余)。显然，为了能够正确解码，接收器就需要能够访问这些先前帧。通常在编码过程中，会不时地插入一个I帧(Intra frame)，由于I帧的编解码过程不依赖于任何先前帧，因此每个视频块就必须从I帧开始(即它们必须从一个GOP的边界开始)。而且，由于后续的视频分块也需要从I帧开始，因此一个视频分块的结尾帧始终是在一个I帧之前(也即是在另一个GOP的边界)。因此COP的长度就需要平衡：较长COP的分块允许更高程度的压缩，但是其切换速度就会比较慢。类似的原理也适用于音频分块，考虑到音频通常是对一系列的样本进行变换编码(例如，AAC每块采用2048个样本)，因此分块只能发生在基于块大小整数倍的地方。
如果考虑不同质量的视频具有不同帧率的情形(而对于音频，则是具有不同的采样频率)，那么事情就会变得更加复杂，因为必须要注意保持块边界是准确对齐的。
值得一提的是，自适应流媒体协议只定义了wire格式，即比特和字节是通过网络发送，它们并不涉及或暗示服务器端的任何信息。这些协议要求每个块必须能够单独寻址，这可以通过让每个块单独成一个文件的方式来实现，但这并不是必须的。事实上，微软的实现方案是在整个持续时间间隔的所有视频块使用同一个文件，一个服务器模块需要负责从中选出正确字节范围的内容来向客户端提供(服务)各个内容分块。这些协议还要求每个分块都可以单独解码，因此就排除了使用SVC编码方案，但服务器可以在内部使用SVC，这样就节省了磁盘容量或回程(backhaul)带宽，并可以在向用户输出分块时再进行转码操作。
主流自适应流媒体方案及其比较
1 三大主流流媒体方案
目前有三家大公司在推动实施它们的解决方案，它们就是微软、苹果和Adobe公司。
微软已经在其Silverlight播放器中集成了“Smooth Streaming”技术方案；而苹果则已经同时在其桌面产品(自从雪豹系统Mac OSX 10.6以后)及其移动产品(自iOS 3以后)中采用了自适应流媒体技术方案；Adobe在其Flash播放器(自从v10.1以后)中实现了“HTTP动态流”的技术方案。显然，每个不同的厂商都有其自己的实现方案，但令人奇怪的是，这些不同的方案间也存在一些共同之处，后面笔者就进行简单的介绍。
微软的实现方案首先使用一个XML类型的“Manifest”文件来和客户端通信URL表，然后通过向一个模板填写所需的参数而构成实际的URL。在一个“分块MP4”容器中的每个文件块要么包含音频资料，要么包含的是视频材料，因此音频和视频请求必须分开，并可以分别切换到不同品质的码流。“分块MP4”格式是ISO规范的一个变种。虽然目前Silverlight播放器只支持H.264和VC-1格式的视频以及AAC和WMA音频格式，但规范本身是与编解码器格式无关的。
与微软的方法不同，苹果的解决方案则是通过使用层次型的文本文件(称为“播放列表”)来通信URL表。顶层播放列表包含各种可用质量的列表，每个表项又有其独立的子播放列表。每个子播放列表明确 列出了每个媒体块的URL。这些分块包含按照MPEG-2 TS(传输流)格式编码的音频和视频。另外，苹果的方案，还支持任何视频和音频的编解码格式，但目前还仅限于实现H.264视频和AAC及MP3音频格式。
而Adobe公司使用的是另外一种XML格式，它拥有自己的MP4变种，该变种对元数据进行了分块处理。虽然目前Flash播放器只支持H.264和VP6视频以及AAC和MP3音频格式，但是和前面两种方案一样，规范本身也是和编解码器格式无关的。
2 自适应流技术方案比较
根据各厂商的技术资料以及相关的参考文献，我们比较了来自新微软、Adobe和苹果的最新的自适应流媒体技术(见表2)。
表格2中相关注解部分的说明：
1)IIS平滑流是Windows Server 2008和Windows Server 2008 R2免费下载的IIS媒体服务的一部分。
2)运行在任何版本的Windows Server 2008或Windows Server 2008R2版本，包括Windows Web服务器，其市场标价为469美元。
3)假设使用Adobe Flash媒体互动服务器支持暂停、搜索、验证以及更高的可扩展性。
4)需要Windows Server 2003 SP2，Windows Server 2008，Red Hat EnterpriseLinux4或红帽企业版Linux5.2。
5)在任何Web服务器上运行，还要求苹果流技术分段器——参见注解6。
6)苹果流媒体分段器是一个工具，它接收编码后的MPEG2-TS流并把它分割成10秒的“块”进行内容交付。该免费下载的工具需要基于Intel架构的Mac电脑，推荐使用Mac Pro或一个具有两个以太网接口的XServe。
7)全部的DVR功能，包括暂停、搜寻、快进(例如，2倍、5倍速播放速度)、快速倒带、Go To Live、即时回放和慢动作播放等。
8)在服务器和客户端之间一个无状态的链接(非持久性的)增加了系统的可扩展性，并允许在负载平衡服务器之间进行无缝的failover和rollover。
9)在2009年10月18日，微软宣布ⅡS媒体服务对苹果iPhone的支持。
10)Adobe公司在2009年9月10日宣布在Adobe Flash Player和Adobe AIR未来的版本支持DRM，计划在2010年上半年交付使用。
11)数字娱乐内容生态系统(DECE，LLC)是一个主要由好莱坞电影公司、消费电子产品制造商和零售商、网络硬件供应商、系统集成和数字版权管理(DRM)供应商一起成立的协会，旨在开发一套数字化发行优质好莱坞节目内容的标准。
12)使用IIS高级的日志记录的扩展对Silverlight应用程序进行实时日志。
13)编码后的直播码流由苹果流分段器进行处理，但该中间步骤可能会导致直播内容的延迟。
走向统一的流媒体技术方案
1 开放标准
除了上述三个“私有”的自适应流媒体方案外，几个标准机构正在开发“开放”的标准。比如，3GPP已经联同OIPF一起定义“基于HTTP的动态自适应流技术方案”。这也是基于XML文件来通信URL，并且是和编解码器格式无关的。它们重用了3GPP现有的容器格式，但据笔者所知，目前还没有基于该标准的实现方案问世。另外，MPEG目前也正在起草“动态自适应HTTP流技术方案”，它考虑同时把3GPP和微软的建议进行标准化。
2 走向统一
如上所述，行业中流行的几种方案除了部分明显的差异性之外，它们也有一些相似之处：三个主流的方案都支持H.264的视频编解码器和常见的AAC音频编解码器。因此，我们可以利用这个事实，对内容按照每种质量只编码一次，然后把视频和音频码流封装到不同的容器中，如iMP4、F4F或MPEG-2 TS流等。从运算的角度来说，编码是运算密集型的，而(重新)封装则是很简单的，因此这种做法的好处是可以“一次编码、多次封装”，能节省不少的运算工作量。
再者，我们可以选择单一的磁盘存储格式：即编码器按照一个公共格式输出码流，然后根据请求实时地重新包装成所需要的媒体格式。这种做法的好处是能够有效地降低所需的磁盘空间，在工作量略有增加的情况下，大概能够节约3倍的空间。这种解决方案实际上已经被微软的IIS服务器所使用，它可以被配置成按照苹果格式进行流媒体输出，与苹果兼容的媒体分块可以由微软SmoothStreaming服务器自动创建。
更进一步，我们甚至可以统一流格式，然后在客户端完成重新包装(Rewrapping)。在这种模式下，最有可能采用的格式将是苹果的格式，因为没有简单的方法可以在苹果的iPhone、iPod、iPad产品系列中植入额外的rewrapping功能逻辑，而Silverlight和Flash两者都嵌入了对应用逻辑的支持，因此rewrapping代码可以和播放器一起进行交付。虽然这看上去有些牵强，但是荷兰的一家公司已在其应用商店中提供了类似的商业模块，能够在Flash播放器中播放Smooth Stream的码流。
小结
富媒体的广泛使用对网络运营商带来了各种各样的挑战，采用先进的编解码技术方案和自适应流技术是两种有效的应对措施。目前，无论是编解码系统，还是自适应流媒体技术都处于不断的发展之中，当然，自适应流媒体方案往往也是建立在高效的编解码系统之上的。
本文主要从编解码器系统和自适应流媒体技术方案这两个方面来介绍相应的解决方案。本文详细地从发展背景、技术细节、主流方案对比、开放标准及发展趋势等几个方面介绍了自适应流媒体技术。限于篇幅，本文没有对编解码器系统进行深入展开，而是就富媒体的挑战探讨了针对性的措施。不过，需要要注意的是，自适应流媒体方案往往建立在高效的编解码系统之上。
富媒体带来的挑战
媒体的发展是从早期单一媒体发展到多媒体，再到如今的富媒体。虽然富媒体能够为用户提供各种各样、功能强大的互动体验，但是，富媒体无论是对内容提供商还是对网络运营商都带来了各种各样的挑战。下面首先来看一下媒体交付领域的混沌景象(见图1)。
图1描述了在媒体交付领域交错复杂的情形。内容提供商包括了媒体公司、出版商和各种企业级的应用；媒体交付网络则包括卫星、有线电视网络、互联网、电信网络(xDSL)、无线网络和企业私有网络等；而媒体消费的种类就更多了：传统电视、互联网电视、个人电脑、(智能)手机、平板电脑、Kiosk和智能电器等。哦，别忘了在内容提供商和网络提供商之间的重要玩家——广告商，它可是广大用户对OTY内容既爱又恨的根源，用户在享受免费媒体内容的时候，不得不承受各种形式广告的“骚扰”。
根据统计，运营商网络中的视频流量按照不同的类型所占的比例如表1所示。
由于OTY内容对于绝大多数的运营商而言是一种负资产，或者被认为是一种管道的泄露(至少在目前是这种情形)，因此如何在避免网络通信管道泄漏的同时推送更多的节目内容是很多运营商迫切希望解决的问题。除此之外，富媒体的流行对运营商还带来了技术和运营方面的各种挑战，下面我们重点介绍这三种挑战。
1 内容是受管理还是不受管理?
为了能够增加业务营运收入，内容提供商和网络运营商都希望能够有效地对内容进行管理，包括版权管理(DRM)、访问控制(CA)以及各种加密措施等。用户访问受管理的内容，往往是需要交费的，换句话说，受管理的内容就等于业务收入。
但是，在另外一方面，存在各种各样的内容商或个人用户，希望能够直接把内容提供给或共享给(其他)用户。他们不希望受运营商的管理，希望其内容能够自由流通。这方面最典型的例子就是Youtube业务。当然，内容提供商(者)可以通过诸如广告赞助的方式获得一部分的资助，而对于网络运营商而言，OTY内容对它们业务的威胁要远远大于其收益(至少在目前是这样的)。这里的威胁主要有以下几方面：
>广告业务收入的流失：由于内容提供商可以和用户自己面对面地沟通，因此就可以跳过网络运营商，广告商也就不用再理会网络运营商了。
>通过自身网络承载的OTT业务对其主要的收费业务造成冲击：最好的例子是Netflix业务，短短几年，Netflix就成为了北美最大的视频业务运营商，其注册用户数超过了北美最大的有线电视运营商Comcast。
>费用的增加：由于网络流量的增加，主要是基于视频的富媒体业务的增加，网络运营商需要为此投入大量的资金和人力来升级其网络基础设施以满足新业务的需要。网络运营商如果仅仅是收取带宽的费用，显然是不够的，尤其是对于有线宽带系统来说。
综上所述，不受管理的内容对运营商而言，其实只是一种费用。
2 不同的节目格式对业务质量的影响
视频节目的来源和格式有多种，例如MPEG2、H.264、MPEG 4、RTSP和HTTP 1.0视频等。另外，用户可以
用多种消费电子设备对媒体内容进行消费，这些设备类型包括各种智能手机、平板电脑、机顶盒、电视机等。
造成节目格式不同的原因有很多。例如，由于历史发展的原因，老的节目内容的格式(如MPEG-2SD／HD)和新的节目格式(如H.264SD／HD)不同。由于牵涉到版权管理和转码费用等问题，不是所有的运营商都愿意把传统格式的节目内容更新到最新的节目格式。另外，由于编码效率的差异，新的节目格式使用6～8M的带宽就能为用户提供高清H.264的节目，而在这种带宽条件下，老节目的效果只能是标清。因此，用户的体验显然是要打折扣的，而也没有人希望从内容提供商处获取质量很差的内容。
另外，别忘了不同格式对存储空间的影响，想想模拟录像带作为存储媒介的年代，太可怕了!因此，为了能够很好地支持基于富媒体的应用，采用高效、灵活的编码系统是必要的。
3 系统演变和融合的需要
早期的视频业务主要是线性、广播式的业务，因此网络基础设施也围绕着广播模式而建立。但是，富媒体更多的是以非线性、互动应用为主，是以数据和IT托管的运营环境为中心而构建的，因此视频业务的基础设施需要从以广播中心向以数据中心进行演变，并采用新的拓扑结构。
综上所述，为了应对富媒体带来的挑战，运营商需要重点关注的细分领域如下：
视频优化：重点是质量、带宽、存储和交互性。
网络优化：涉及流量管理、数据包检测服务质量、SLA等。
下面，我们重点从编解码器和自适应流媒体技术这两方面来探讨运营商如何应对“大文件、细管道”的问题。
采用先进编解码器的解决方案
如何才能在现有的网络基础上(“细管道”)“挤进”更多的节目内容或新业务(“大文件”)?一个很明显的解决方案就是采用先进的编解码器方案。我们的目标是要能够以最低的带宽获得最多的节目内容(或最高质量内容)，那么，该如何选择编解码器系统?下面就针对此罗列了一些关键性的需求和指标。
首先要做的是对内容的管理和优化。
>编码器方案应该是一个多用途的编码平台，要求能够在线性和视频点播应用之间进行动态切换，而且能够支持动态的“换码”(transcoding)应用。
>编解码器方案要能够与其他系统组件进行无缝集成，因此要求提供API的支持、易于自定义工作流、避免私有、专门的和单用途的系统方案。
>具有动态的适应性，支持自适应流媒体方案(下面有重点介绍)，能够建立量化的质量指标，并可对响应系统进行智能性的设置。
其次是要把不同的内容格式进行规整，能达到对视频资产进行优化管理的目标。
>从单一输入获得多重输出，即针对同一个节目内容，一次编码过程可以得到多种不同质量和码率的版 本。同时生成多种版本的资产，一方面可以应对不同的用户设备使用不同的接入技术对节目内容的访问，同时也可以增加资产的回报率。
>对内容格式进行规整，可以减少格式的种类。这一方面可以减轻存储负担，另一方面还可以减少需要保存的内容资产数量。如果把进行版权管理、加密和水印等保护措施的费用算进去，减少格式种类，是最直接了当的节省费用的方法。
>动态转码，即根据用户的需要进行转码。这样做的好处是一方面可以保持原有的授权，另一方面，还可以加强SLA性能，实现更低的延迟。
再有，就是要进行系统的融合，目标是以更低的成本进行统一的网络运营。
>发展以数据为中心的拓扑结构，通过工作流程、存储、网络、数据、客户关系管理和SLA等进行API的规范标准化，这样就可以便于业务在未来进行扩展和升级。
>开发统一的管理门户网站，为用户提供单点登录等功能，并提升用户的服务体验。
>优化工作流程，争取实现实时智能和反馈驱动的流程。
自适应流媒体技术
互联网一直处于不断地发展与演变之中。早期，网页页面虽然是纯粹由文字构成，但是图像很快就被纳入页面之中，并成为不可或缺的元素；进而是移动图片的出现，其形式主要是“动画GIF”；而真正全面支持视频内容则是最近几年的事情。
如今，视频播放在网络上可谓无处不在，可是要想获得流畅的播放体验并不总是如人所愿的，用户总会碰到这样或那样的问题：启动时间太长、无法检索并定位到任意的视频播放点、当视频重新缓冲时常常造成视频播放的中断等。好在在过去几年里，出现了一些新的视频交付技术，能够有效地解决这些问题，本文着重介绍其中之一的“自适应流媒体技术”。
1 流媒体技术发展背景
要在互联网上进行通信，就需要使用互联网协议(IP)，它通常是和传输控制协议(TCP)一起工作。IP协议负责把数据包通过互联网交付给请求的主机；TCP则保证所有的数据包能够按照正确的顺序无损地到达接收方。当然如果有必要的话，还需要重新排序数据包或要求重新传输丢失的数据包。
在互联网上保证文件的可靠传输是至关重要的，但要实现这些差错纠正功能也是需要付出代价的。TCP协议拒绝提供下一个数据包之外的任何东西，即使其他的数据包已经到达用户设备处并在缓冲区中处于等待状态(例如，一种可能的情形是当TCP正在等待一个重传数据包的到来)。虽然这种机制对于文件下载是很理想的，但是对于视频和音频下载播放的情形就不太适用了：因为在音视频播放过程中，通常是倾向于跳过缺失的数据包，这虽然会造成短暂的声音或视觉方面的抖动现象，但总比播放处于中止状态，一直等到丢失的数据包重新被传送过来要好很多。
为此，早先的流媒体传输协议，如实时传输协议(RTP)就没有选择使用TCP的纠错功能，而是选择使用了用户数据包协议(UDP)。UDP只过滤掉受损的数据包，但并不试图进行任何的差错校正。RTP协议仍然是目前最流行的音频和视频流传输协议之一，特别是在IP电话(VoIP)和视频通信等应用方面。但是，由于它缺乏对差错的纠正能力，因此RTP主要应用于受管理的内部网络。此外，大多数网络用户和互联网的防火墙通常都被配置成不允许UDP流量，换句话说，也不支持RTP业务流量。
超文本传输协议HTTP被广泛应用于互联网，并几乎服务于每个网站，而且绝大多数的防火墙都支持HTYP协议，虽然有时需要通过代理服务器来完成。因此，HTYP是一种非常具有吸引力的协议，它可以用于向广大的用户交付各种内容，当然也包括视频在内。通过HTFP交付视频最简单的方式，就是被称为HTTP下载的方式：多媒体文件被当成正常文件进行处理，并在互联网上进行传输，它同时还具备TCP的纠错能力。一旦文件完全下载后，就可以对文件进行播放——通常是在一个独立的播放器中进行的，当然也可以通过浏览器插件的方式进行播放。尽管该技术方案能够保证以最优的质量进行完全无缝地回放，但是也有缺点，就是用户需要耐心的等待，直到该文件完全下载之后才能进行播放操作。
另外一种用户体验更好的方法是预先准备好多媒体播放所需要的信息，用户可以边下载边播放。其具体方法是把所有需要开始播放的信息都挪到文件的开始处，这样智能客户端一旦下载了文件的开始部分，就有了播放所需要的所有信息，这样就可以马上开始播放，即使文件仍然处于下载的过程中!而且，这种方案对于服务器端没有特别的要求——仍然只需提供正常的下载文件。这种技术被称为渐进式下载。显然，下载速度要快到足以超过播放的速度，否则就需要对媒体内容进行重新缓冲，而如前所说，重新缓冲往往会造成播放中断，甚至需要重新启动播放过程等。另外，在这种情况下，用户搜寻任意播放时间点的能力是被降低的：只可能搜寻已经下载的部分。
当然，这种限制很快地就被一种更加聪明的方案所克服，新方案采用了一种更聪明的服务器，它能够理解多媒体文件的内部结构。在这种“伪”HTTP流传输方案中，客户端可以请求下载某个特定时间间隔的文件，因此在无需下载整部电影的情况下，就可以搜寻你所最喜爱的场景。然而，一旦客户端开始下载，它仍然需要尽可能快地下载(如同所有的HTTP下载情形)，如果你不准备观看整部视频时，这种方案会造成大量的带宽浪费。对这种方案的改进方法包括限制客户端或服务器的下载速度，使其能够“刚刚足够快”。但这种方案仍然存在一些问题，限于篇幅，我们不在这里赘述。
上述的技术方案都使用单一的“对话”来传输所有需要的媒体数据。当用户处于移动状态时，这就会有问题：例如，当某个智能手机超出了一个Wi-Fi的热点范围，它可以自动切换到一个蜂窝数据连接(如UMTS和EDGE和GPRS等)。然而，这种“漫游”会导致所有的活动会话中断，因此需要重新启动所有的会话连接。最重要的是，新的蜂窝连接很可能只能提供较少的带宽，而且该带宽很可能太低，以至无法继续支持用户在Wi-Fi热点中所使用的较高的视频比特率。
至此，自适应流媒体传输方案就应运而生了。
2 自适应流媒体技术方案
自适应流媒体方案一方面结合了上述诸多协议的优点，另外一方面努力摈弃了原有方案固有的一些缺点。虽然自适应流媒体技术可以运行在各种各样的协议之上，但它们通常是运行在HTTP协议之上，因此可以不费事地通过大多数的防火墙。使用HTTP还有其他优点，例如，缓存功能是建立在该协议核心之上的：每个HTTP对象都包含一个标签(tag)，它指定了该对象的有效时间，如果在这个时间跨度内被再次请求的话，那 么可以直接使用保存的副本而不用去麻烦原始服务器了。这样就可以减轻原始服务器的负载，因为系统自动把负载分摊给了边缘服务器(代理服务器或专门的缓存服务器)。
图2是负载分摊的示意图。初始请求将被转发到源服务器，一旦响应被检索到，它被存储在一个边缘缓存服务器中并传递给请求客户端。针对该对象的所有后续请求都将由该高速缓存区服务。一旦该对象不再有效(由原始服务器指定时间间隔)的话，它就从高速缓存中被删除。注意，即使对象有效，也有可能被高速缓存管理应用程序删除以便腾出更多的空间给热门的对象。
在服务器端，使用HTTP的另外一个好处是：这是一个无状态的协议。在一个无状态的协议中，服务器不用存储任何有关客户端或其请求的持久性信息，换句话说，一旦请求被处理，那么服务器就被重置到其原始状态(如果需要一个持久性的存储空间，那么就需要在HTTP之上进行处理，服务器通常使用一个数据库来存储持久信息)。该特点非常利于负载平衡：因为每个请求都可以由任何可用的服务器进行处理，而不需要跟踪是哪个服务器“拥有”哪些特定的客户端。
从服务器的角度来看，自适应流媒体技术其背后的基本原理相当简单：为客户端提供一个网址(URL)表，每个URL指向同一个内容的特定质量版本(如图3中的行)的特定时间间隔(如图3中的列)的视频片段，具体如图3所示。所有的智能性都是在客户端实现的，服务器可以是任何和HTTP兼容的设备，只要能服务常规的文件。
媒体文件被创建成多种质量版本的媒体流，在这里由不同的行代表；同时，这些不同质量的媒体流也被切成不同间隔的时间段(这里由不同的列代表)，并且每个不同质量版本的媒体流的时间间隔是同步的。每个单独分割的块都可以被客户端单独访问到。本示例使用的是固定大小的块，但在实际应用中可以大小不一样。
一旦客户端下载了URL表格，就需要利用客户端系统的信息来选择合适的URL，以便获取下一个内容块。显然，客户端应该从第一个时间间隔的内容块开始播放，但问题是该选用哪个质量版本的内容?通常，客户端都是从最低可用质量的版本开始，这将提供最快速的启动时间。在第一个内容块的下载过程中，系统能够估计可用的网络带宽信息：举例来说，第一个内容块的大小为400KB，而其下载时间为1.5秒，那么可以估算出网络带宽大概为2Mbps。随后，客户端通常就切换到在网络带宽可用范围之内的最高质量的内容版本。另外，搜寻节目内容的一个任意播放点也是可能的：客户端可以计算出相应的时间间隔，并马上请求该部分的内容块。
当然，具体的实现方案可以使用更多的指标而不仅仅是带宽。例如，客户端可以检测目前播出的视频分辨率，这样嵌入在Web页面中的一个微型／缩略图视频播放器就可以下载低分辨率的视频版本，即使当前的网络带宽可以支持更好的视频质量，也只有当处于全屏播放模式时，才切换到高清版本。客户端也可以把可用的CPU能力(或硬件支持)考虑进去，这样即使网络带宽支持更高的比特率，但由于硬件能力的限制，只能采用较低的视频版本，从而可以消除视频播放卡顿的现象。
为了实现码流的无缝切换和播放，对各个视频分块就有一些明确的要求。由于客户可以选择任意质量的任意一个分块，因此各个分块就必须是完全独立的。现代视频编码算法都使用“帧间压缩”算法：需要使用先前的视频帧来构建当前帧，并只发送这些视频帧之间的差异(从而达到压缩空间和时间上的冗余)。显然，为了能够正确解码，接收器就需要能够访问这些先前帧。通常在编码过程中，会不时地插入一个I帧(Intra frame)，由于I帧的编解码过程不依赖于任何先前帧，因此每个视频块就必须从I帧开始(即它们必须从一个GOP的边界开始)。而且，由于后续的视频分块也需要从I帧开始，因此一个视频分块的结尾帧始终是在一个I帧之前(也即是在另一个GOP的边界)。因此COP的长度就需要平衡：较长COP的分块允许更高程度的压缩，但是其切换速度就会比较慢。类似的原理也适用于音频分块，考虑到音频通常是对一系列的样本进行变换编码(例如，AAC每块采用2048个样本)，因此分块只能发生在基于块大小整数倍的地方。
如果考虑不同质量的视频具有不同帧率的情形(而对于音频，则是具有不同的采样频率)，那么事情就会变得更加复杂，因为必须要注意保持块边界是准确对齐的。
值得一提的是，自适应流媒体协议只定义了wire格式，即比特和字节是通过网络发送，它们并不涉及或暗示服务器端的任何信息。这些协议要求每个块必须能够单独寻址，这可以通过让每个块单独成一个文件的方式来实现，但这并不是必须的。事实上，微软的实现方案是在整个持续时间间隔的所有视频块使用同一个文件，一个服务器模块需要负责从中选出正确字节范围的内容来向客户端提供(服务)各个内容分块。这些协议还要求每个分块都可以单独解码，因此就排除了使用SVC编码方案，但服务器可以在内部使用SVC，这样就节省了磁盘容量或回程(backhaul)带宽，并可以在向用户输出分块时再进行转码操作。
主流自适应流媒体方案及其比较
1 三大主流流媒体方案
目前有三家大公司在推动实施它们的解决方案，它们就是微软、苹果和Adobe公司。
微软已经在其Silverlight播放器中集成了“Smooth Streaming”技术方案；而苹果则已经同时在其桌面产品(自从雪豹系统Mac OSX 10.6以后)及其移动产品(自iOS 3以后)中采用了自适应流媒体技术方案；Adobe在其Flash播放器(自从v10.1以后)中实现了“HTTP动态流”的技术方案。显然，每个不同的厂商都有其自己的实现方案，但令人奇怪的是，这些不同的方案间也存在一些共同之处，后面笔者就进行简单的介绍。
微软的实现方案首先使用一个XML类型的“Manifest”文件来和客户端通信URL表，然后通过向一个模板填写所需的参数而构成实际的URL。在一个“分块MP4”容器中的每个文件块要么包含音频资料，要么包含的是视频材料，因此音频和视频请求必须分开，并可以分别切换到不同品质的码流。“分块MP4”格式是ISO规范的一个变种。虽然目前Silverlight播放器只支持H.264和VC-1格式的视频以及AAC和WMA音频格式，但规范本身是与编解码器格式无关的。
与微软的方法不同，苹果的解决方案则是通过使用层次型的文本文件(称为“播放列表”)来通信URL表。顶层播放列表包含各种可用质量的列表，每个表项又有其独立的子播放列表。每个子播放列表明确 列出了每个媒体块的URL。这些分块包含按照MPEG-2 TS(传输流)格式编码的音频和视频。另外，苹果的方案，还支持任何视频和音频的编解码格式，但目前还仅限于实现H.264视频和AAC及MP3音频格式。
而Adobe公司使用的是另外一种XML格式，它拥有自己的MP4变种，该变种对元数据进行了分块处理。虽然目前Flash播放器只支持H.264和VP6视频以及AAC和MP3音频格式，但是和前面两种方案一样，规范本身也是和编解码器格式无关的。
2 自适应流技术方案比较
根据各厂商的技术资料以及相关的参考文献，我们比较了来自新微软、Adobe和苹果的最新的自适应流媒体技术(见表2)。
表格2中相关注解部分的说明：
1)IIS平滑流是Windows Server 2008和Windows Server 2008 R2免费下载的IIS媒体服务的一部分。
2)运行在任何版本的Windows Server 2008或Windows Server 2008R2版本，包括Windows Web服务器，其市场标价为469美元。
3)假设使用Adobe Flash媒体互动服务器支持暂停、搜索、验证以及更高的可扩展性。
4)需要Windows Server 2003 SP2，Windows Server 2008，Red Hat EnterpriseLinux4或红帽企业版Linux5.2。
5)在任何Web服务器上运行，还要求苹果流技术分段器——参见注解6。
6)苹果流媒体分段器是一个工具，它接收编码后的MPEG2-TS流并把它分割成10秒的“块”进行内容交付。该免费下载的工具需要基于Intel架构的Mac电脑，推荐使用Mac Pro或一个具有两个以太网接口的XServe。
7)全部的DVR功能，包括暂停、搜寻、快进(例如，2倍、5倍速播放速度)、快速倒带、Go To Live、即时回放和慢动作播放等。
8)在服务器和客户端之间一个无状态的链接(非持久性的)增加了系统的可扩展性，并允许在负载平衡服务器之间进行无缝的failover和rollover。
9)在2009年10月18日，微软宣布ⅡS媒体服务对苹果iPhone的支持。
10)Adobe公司在2009年9月10日宣布在Adobe Flash Player和Adobe AIR未来的版本支持DRM，计划在2010年上半年交付使用。
11)数字娱乐内容生态系统(DECE，LLC)是一个主要由好莱坞电影公司、消费电子产品制造商和零售商、网络硬件供应商、系统集成和数字版权管理(DRM)供应商一起成立的协会，旨在开发一套数字化发行优质好莱坞节目内容的标准。
12)使用IIS高级的日志记录的扩展对Silverlight应用程序进行实时日志。
13)编码后的直播码流由苹果流分段器进行处理，但该中间步骤可能会导致直播内容的延迟。
走向统一的流媒体技术方案
1 开放标准
除了上述三个“私有”的自适应流媒体方案外，几个标准机构正在开发“开放”的标准。比如，3GPP已经联同OIPF一起定义“基于HTTP的动态自适应流技术方案”。这也是基于XML文件来通信URL，并且是和编解码器格式无关的。它们重用了3GPP现有的容器格式，但据笔者所知，目前还没有基于该标准的实现方案问世。另外，MPEG目前也正在起草“动态自适应HTTP流技术方案”，它考虑同时把3GPP和微软的建议进行标准化。
2 走向统一
如上所述，行业中流行的几种方案除了部分明显的差异性之外，它们也有一些相似之处：三个主流的方案都支持H.264的视频编解码器和常见的AAC音频编解码器。因此，我们可以利用这个事实，对内容按照每种质量只编码一次，然后把视频和音频码流封装到不同的容器中，如iMP4、F4F或MPEG-2 TS流等。从运算的角度来说，编码是运算密集型的，而(重新)封装则是很简单的，因此这种做法的好处是可以“一次编码、多次封装”，能节省不少的运算工作量。
再者，我们可以选择单一的磁盘存储格式：即编码器按照一个公共格式输出码流，然后根据请求实时地重新包装成所需要的媒体格式。这种做法的好处是能够有效地降低所需的磁盘空间，在工作量略有增加的情况下，大概能够节约3倍的空间。这种解决方案实际上已经被微软的IIS服务器所使用，它可以被配置成按照苹果格式进行流媒体输出，与苹果兼容的媒体分块可以由微软SmoothStreaming服务器自动创建。
更进一步，我们甚至可以统一流格式，然后在客户端完成重新包装(Rewrapping)。在这种模式下，最有可能采用的格式将是苹果的格式，因为没有简单的方法可以在苹果的iPhone、iPod、iPad产品系列中植入额外的rewrapping功能逻辑，而Silverlight和Flash两者都嵌入了对应用逻辑的支持，因此rewrapping代码可以和播放器一起进行交付。虽然这看上去有些牵强，但是荷兰的一家公司已在其应用商店中提供了类似的商业模块，能够在Flash播放器中播放Smooth Stream的码流。
小结
富媒体的广泛使用对网络运营商带来了各种各样的挑战，采用先进的编解码技术方案和自适应流技术是两种有效的应对措施。目前，无论是编解码系统，还是自适应流媒体技术都处于不断的发展之中，当然，自适应流媒体方案往往也是建立在高效的编解码系统之上的。