收藏 分享(赏)

浅谈HTTP Adaptive Streaming技术及其前景.docx

上传人:cjc2202537 文档编号:5544534 上传时间:2019-03-07 格式:DOCX 页数:11 大小:777.37KB
下载 相关 举报
浅谈HTTP Adaptive Streaming技术及其前景.docx_第1页
第1页 / 共11页
浅谈HTTP Adaptive Streaming技术及其前景.docx_第2页
第2页 / 共11页
浅谈HTTP Adaptive Streaming技术及其前景.docx_第3页
第3页 / 共11页
浅谈HTTP Adaptive Streaming技术及其前景.docx_第4页
第4页 / 共11页
浅谈HTTP Adaptive Streaming技术及其前景.docx_第5页
第5页 / 共11页
点击查看更多>>
资源描述

1、 1 / 11浅谈 HTTP Adaptive Streaming 技术及其前景(2011-09-02 17:40:05)转 载 关键词:OTT 流媒体 HTTP Adaptive Streaming本文已发表于世界宽带网络2011.6 第 18 卷第 5 期 总 200 期HTTP Adaptive Streaming(以下简称“HAS”)技术结合了传统的流媒体技术和 HTTP渐进式下载播放的特点,以 HTTP 的方式向用户传送媒体内容,该技术的采用可以大大提升用户的媒体播放体验,同时该技术降低了头端服务器的技术复杂度。基于 HTTP 的传送方式提升了媒体内容在网络设备中的穿透能力,该技术目

2、前已成为流媒体视频行业发展的趋势。一、传统流媒体技术近些年,互联网视频迅猛发展,视频内容的流量已占到了整个互联网流量的一半。谈到互联网视频就不得不提到流媒体技术,正是流媒体技术的不断发展促进了目前互联网视频的迅猛发展。传统的媒体内容分发技术主要有两大类,一类是以 RTSP/RTP(Real Time Streaming Protocol/Real Time Transfer Protocol)为代表的面向连接的流媒体技术,另一类则是目前主流视频网站采用的无连接的 HTTP 渐进式下载。1.RTSP/RTP 的流媒体方案RTSP 是一种传统的流媒体控制协议,其具有状态性的特点意味着从一个客户端开

3、始连接至服务端一直到连接中断的整个过程,服务端会一直监听客户端的状态。客户端通过RTSP 协议向服务器传达控制命令,如播放、暂停或中断等。RTP/RTCP(Real Time Transfer Control Protocol)是端对端基于组播的应用层协议。其中,RTP 用于数据传输,RTCP 用于统计、管理和控制 RTP 传输,两者协同工作,能够显著提高网络实时数据的传输效率。基于此架构的流媒体技术方案,服务端和客户端之间建立连接之后,服务器开始持续不断地发送媒体数据包,媒体数据包采用 RTP 进行封装,客户端控制信息通过 RTSP 信息包以 UDP 或 TCP 的方式传送。2 / 11另外

4、,类似的流媒体协议还包括了 Adobe 的 RTMP(Real Time Messaging Protocol)以及 Real 公司的 RTSP over RDT(Real Data Transport Protocol),本文就不在此对这些流媒体协议逐一进行介绍了。2.HTTP 渐进式下载HTTP 渐进式下载技术与有状态的 RTSP/RTP 技术相比,采用了无状态的 HTTP 协议。当HTTP 客户端向前端请求数据时,服务端将请求的数据下发给客户端,但是服务端并不会记录客户端的状态,每次 HTTP 请求都是一个一次性独立的会话。渐进式下载的功能目前主流的终端播放器均支持,如 Adobe 的

5、Flash、微软的Silverlight 以及 Windows Media Player。所谓的渐进式下载,即终端播放器可以在整个媒体文件被下载完成之前即可开始媒体的播放,客户端及服务端如果均支持 HTTP1.1,终端还可从没下载完成的部分中任意选取一个时间点开始播放。目前,主流的视频网站均采用了 HTTP 渐进式下载的方式来实现流媒体的分发,如优酷网、土豆网等等。3.方案对比作为最简单和原始的流媒体解决方案,HTTP 渐进式下载尤其显著的优点在于它仅需要维护一个标准的 Web 服务器,其安装和维护的工作量和复杂性比起专门的流媒体服务器来说要简单和容易得多。3 / 11然而,其缺点和不足也很明

6、显。首先是带宽容易浪费。当一个用户在开始下载观看一个内容之后选择停止观看,那么已经下载完成的内容则是对带宽资源的一种浪费。其次,基于 HTTP 的渐进式下载仅仅适用于点播内容,而不支持直播内容。最后,此方式缺乏灵活的会话控制功能和智能的流量调节机制。而基于 RTSP/RTP 的流媒体系统专门针对大规模流媒体直播和点播等应用而设计,需要专门的流媒体服务器支持,与 HTTP 渐进下载相比主要具有如下优势。 流媒体播放的实时性。与渐进下载客户端需要先缓冲一定数量媒体数据才能开始播放不同,基于 RTSP/RTP 的流媒体客户端几乎在接收到第一帧媒体数据的同时就可以启动播放。 支持进度条搜索、快进、快退

7、等高级 VCR 控制功能。 平滑、流畅的音视频播放体验。在基于 RTSP 的流媒体会话期间,客户端与服务器之间始终保持会话联系,服务器能够对来自客户端的反馈信息动态做出响应。当因网络拥塞等原因导致可用带宽不足时,服务器可通过适当降低帧率等方式来智能调整发送速率。 支持大规模用户扩展。普通的 Web 服务器主要针对大量小的 HTML 文件下载而进行优化,在传输大容量媒体文件方面缺少性能优势。而专业的流媒体服务器在大容量媒体文件硬盘读取、内存缓冲和网络发送等方面进行了优化,可支持大规模用户接入。 内容版权保护。在渐进下载模式中,下载后的文件缓存在客户端硬盘的临时目录中,用户可将其拷贝至其他位置供以

8、后再次播放。而在基于 RTSP/RTP 的流媒体系统中,客户端只在内存中维持一个较小的解码缓冲区,播放后的媒体数据随时清除,用户不容易截取和拷贝。此外还可利用 DRM 等版权保护系统进行加密处理。尽管如此,基于 RTSP/RTP 的流媒体系统在实际的应用部署中仍然遇到了不少问题,主要体现在: 与 Web 服务器相比,流媒体服务器的安装、配置和维护都较为复杂,特别是对于已经建有 CDN(内容分发网络)等基础设施的运营商来说,重新安装配置支持RTSP/RTP 的流媒体服务器工作量很大; RTSP/RTP 协议栈的逻辑实现较为复杂,与 HTTP 相比支持 RTSP/RTP 的客户端软硬件实现难度较大

9、,特别是对于嵌入式终端来说; RTSP 协议使用的网络端口号(554)可能被部分用户网络中的防火墙和 NAT 等封堵,导致无法使用。虽然有些流媒体服务器可通过隧道方式将 RTSP 配置在 HTTP 的80 端口上承载,但实际部署起来并不是特别方便。二、HTTP 码率自适应上一节中我们谈到了基于 RTSP/RTP 的流媒体技术以及基于 HTTP 的渐进式下载,但是我们可以清楚看到两种方案均存在着各自的缺点。这时 HAS 技术应运而生,它融合了传统 RTSP/RTP 流媒体技术以及基于 HTTP 渐进式下载技术的优点,具有高效、可扩展以及兼容性强的特点。下图为 HAS 技术的实现原理。4 / 11

10、HAS 技术是一种混合的媒体分发方式,给用户的体验是流的方式,但是实际上与 HTTP渐进式下载方式一样采用 HTTP 协议完成了内容的下载分发,但这些媒体内容都被切割成了一系列的媒体分块进行传输。HAS 技术的一个关键就是媒体数据的切割分块,每个分块的时间长度相同,一般为210 秒。在视频编码层,这意味着每个分块都由若干个完整的视频 GOP 组成(每个分块都有一个关键 I 帧),以此保证每个分块都与过去及将来的媒体分块无关联。媒体分块存储在 HTTP Web 服务器中,客户端以线性的方式向 Web 服务器请求媒体分块,并以传统的 HTTP 方式进行媒体分块的下载,当媒体分块下载至客户端时,客户

11、端按照顺序播放这一系列媒体分块。因为这些媒体分块按照约定的规则进行编码,各个媒体分块之间没有内容的重叠或不连续,对于用户来说,则看到了一个无缝平滑的播放效果。5 / 11若一份内容在编码输出时已提供了多种码率,则内容切片模块会将其切割成多种码率的媒体分块。因为 Web 服务器传输数据是尽可能地利用网络带宽来进行内容的下载,没有流量的控制机制,客户端可以很容易地检测到 Web 服务器到客户端的可用网络带宽,从而决定下载更大或更小的媒体分块,实现码率的自适应。从图 5 我们可以看出,HAS 的关键技术主要由两大部分,一是内容的准备,包括了支持多屏的转码平台以及媒体的分割切片模块,其次是内容的分发,

12、包括了基于 HTTP 的内容源服务器以及面向终端的内容分发网络,完成并发流数量的放大功能。三、HAS 技术特点分析1.采用 HAS 的优势HAS 与其他基于 HTTP 传输媒体的方式一样,和传统的流媒体分发技术相比,具有以下优势: Web 服务器更容易部署,因为 HAS 技术采用了通用的 HTTP 协议,传统的 HTTP缓存/代理、防火墙等网络设备可以完美兼容; 提供了更好的兼容性和到达率,可根据最后接入网的带宽大小动态地调整码率,实现内容的分发; 对于用户来说体验更好,且不需要业务提供者去考虑收看用户的带宽。HAS 除了上述优势之外,还有以前任何技术均不具备的特点,具体如下: 用户等待的时间

13、更短,可以快速实现播放客户端初始化默认选择低码率,开始播放后逐步向高码率进行切换,因此,其服务质量是在可用带宽范围之内不断被进行调整和优化; 不需要大的缓存,不间断地播放,没有抖动的平滑视频播放体验; 基于网络状况和 CPU 解码能力的无缝码率切换; 客户端不需要下载超过它实际消耗的内容。综上所述,相对于传统的流媒体技术,它能够提供更好的服务质量,因为它可以使用整个可用的带宽,而非自适应流技术则是强制客户端选择一个低于可用带宽的固定比特率。可以预见,HAS 技术在不久的将来将得到广泛的部署及应用。2.需要面对的问题6 / 11上一节我们谈到了 HAS 的优势及技术实现原理,似乎 HAS 的实现

14、非常简单,首先在内容准备上提供多个码率的媒体文件,并提供一个索引文件,其中记录了各个码率文件的关系及特性,接下来终端根据初始的带宽情况选择一个码率的媒体文件进行顺序播放,期间根据网络情况以及 CPU 的负载调整码率。但是 HAS 技术方案具体部署实施时有许多问题需要去明确,如果这些问题没有得到很好的解决,则无法提供最佳的用户体验。 采用几个码流? 码流的分辨率? 关键帧间隔? VBR or CBR? 音频参数的设置?四、HAS 企业方案及技术标准目前,HAS 技术的实现方式从标准的类型来看主要有两大类:一类是企业方案,即提供了整体的技术解决方案,如 Apple Live Streaming 技

15、术、Microsoft Smooth Streaming技术、Adobe Dynamic Streaming 技术;一类则是一些国际标准组制定的技术标准,如OIPF 的 HTTP Adaptive Streaming、MPEG 的 DASH(Dynamic Adaptive Streaming over HTTP)、IETF 的草案(由 Apple 公司提议的草案)。1.OIPFOPEN IPTV Forum 在其定义的 OIPF 技术规范中对码率自适应技术进行了界定,规范中对如何实现 HTTP 码流自适应的理论进行了细化及扩展,明确了如何使用及使用的范围。该标准以 3GPP 的 Adapti

16、ve HTTP Streaming 技术规范为基础进行相关的扩展,增加了对MEPG-2 TS 格式的支持。OIPF 的码率自适应标准中对终端下载的索引文件进行了定义,OIPF 中将索引文件命名为 MPD(Media Present Description)文件,采用 XML 格式进行组织。同时 OIPF 标准规定了媒体的封装格式为 TS 和 MP4,并且对分片的一些细节进行了界定,如同一内容的不同码率的文件必须使用同样的媒体封装格式,但是编码的 Profile 可以不同。该标准对直播应用场景以及快进、快退、定位等操作均进行了定义。2.MPEG近来,MPEG 标准发布了一项关于 HTTP Str

17、eaming 的标准 DASH,见图 6。7 / 11DASH 标准对目前出现的 HAS 技术框架进行了总结归纳,对背景、目的以及使用场景进行了介绍。该标准中定义了一系列的使用场景,如 3D Video、互动 3D、动态码率自适应、Peer-2-Peer 以及多画面电视,同时还对如何与内容保护技术结合进行了定义。DASH 标准的制定主要为了解决以下问题: 更为有效地将 MPEG 的媒体通过 HTTP 协议,以自适应、渐进式、下载或流的方式进行内容分发; 支持直播业务; 更为有效地利用传统的基于 HTTP 的 CDN 网络、代理 Server 或防火墙等网络基础部件; 支持与内容保护系统的结合,

18、完成对内容的保护。总的来说,DASH 对采用 HTTP 传输 MPEG 媒体涉及到的各方面提出了一系列的技术要求,包括了媒体内容格式、传输方式、MPD 文件、业务控制、自适应以及媒体保护等。3.Apple HTTP Live Streaming(IETF)HTTP Live Streaming 是 Apple 公司的 HAS 整体解决方案,该方案设计的目标主要是通过普通的 Web 服务器将直播内容或点播内容推送至 Apple 的终端设备,如 iPhone、iPad以及苹果的台式机。Apple 公司的技术规范现已提交至 IETF 组织讨论,目前还在标准的草案阶段。HTTP Live Stream

19、ing 由三部分组成:服务器组件、分发组件和客户端。首先,编码器接收音视频输入,并采用 H.264 编码技术,输出 MPEG-2 TS 流,然后利用切片软件按设定的时间间隔对 TS 码流进行切割并保存为一个个 TS 文件。这些 TS 文件部署在 Web 服务器上,切片软件同时还创建了包含这些 TS 文件相关信息的索引文件。索引文件的 URL 在 Web8 / 11服务器上发布,客户端读取索引文件,然后按顺序向服务器请求媒体文件并无停顿地显示它们。一个简单的 HTTP Live 媒体流配置如图 10 所示。在苹果的动态码率自适应体系中,索引文件被保存为.M3U8 文件,这是保存 MP3 播放列表

20、的.M3U 格式的一种扩展。HTTP Live Streaming 支持实时广播会话和视频点播会话两种应用场景。对于实时会话来说,当新的媒体文件被创建时,索引文件也会随之更新,旧的索引文件通常会被删除。更新的索引文件会在连续流中显示一个移动的窗口,这种类型的会话适合连续的直播内容。对于视频点播会话,媒体文件在整个会话周期内都是固定不变的。索引文件是静态的,只需在媒体开始播放前获取一次,其包含了所有媒体文件的完整列表。目前,HTTP Live Streaming 没有考虑对 DRM 的完整支持,但它支持内容的加密,通过 16 位密钥的 AES-128 加密算法对内容加密,HTTP Live St

21、reaming 中仅对如何通过 URI获取密钥进行了粗略的定义。4.Microsoft Smooth StreamingSmooth Streaming 是微软提供的一套 HAS 解决方案,基于 Microsoft 的头端 Web 服务IIS 7 以及其终端的 Silverlight 技术。微软的 Smooth Streaming 选择了 MPEG-4 格式为媒体封装格式,Smooth Streaming 将每个分片都用 MPEG-4 封装成一个 MPEG-4 的Fragment,但是存储为一个完整连续的 MP4 文件,事实上媒体仅仅是做了虚拟的分片。当终端的播放 URL 的请求上来时,头端服

22、务器需要准确地分析 URL 请求,并将其转化为精准的偏离量,从而找到对应的媒体数据块分发给终端。之所以选择 MP4 作为媒体文件格式,主要是因为 MP4 相比于 ASF 是一个轻量级的容器,更容易使用.NET 进行管理和控制,同时 MP4 是基于广泛应用的 ISO Base Media 文件格式9 / 11规范,最重要的一点是 MP4 设计之初就考虑支持在一个文件内实现媒体内容负荷的分片。微软 Smooth Streaming 存储媒体格式、传输媒体格式分别见图 7、图 8 所示。从图 8 我们可以很清楚地看出,Smooth Streaming 采用的是一种虚拟切片的技术,微软的 HTTP 码

23、率自适应技术并没有真实地将媒体文件进行切片,每个码率对应的内容存储成了一个完整长度的文件,在实际播放过程中,根据终端的请求将每个 Fragment 独立分发给终端。Smooth Streaming 终端基于 Silverlight 进行实现,Silverlight 可完成 MPEG-4 文件格式的解析、HTTP 下载以及码率的切换。同时微软将这些功能以.NET 代码的形式提供给10 / 11开发者调用,开发者可对播放器的效果进行优化及调整。播放器的开发工作中最为复杂的模块是码率的切换模块,何时切换以及如何切换是此模块的核心功能,也是技术难点,如果想给用户最佳的体验,必须考虑以下问题。 当用户有

24、足够的带宽但是 CPU 解码能力不足时该如何处理? 当视频播放被用户暂停或隐藏在背后时该如何处理? 当最佳的视频质量的分辨率超出了屏幕本身的分辨率时该如何处理? 下载播发的 Buffer 窗口该设置为多大? 当在播放过程中需要插入新的媒体内容如插播一段广告时该如何保证无缝的切换?5.Adobe HTTP Dynamic StreamingAdobe 公司的传统流媒体解决方案 RTMP+FLV 的组合,在互联网视频行业得到了广泛的应用。针对动态码率自适应的需求,Adobe 公司首先在其传统的解决方案上实现了码率自适应,但随后不久 Adobe 公司也推出了基于 HTTP 的码率自适应解决方案 HT

25、TP Dynamic Streaming,见图 9。Adobe HTTP Dynamic Streaming 包含了多个部件来完成内容的准备工作,并通过HTTP 将内容传送给终端的 Flash Player。内容准备模块包括了面向 VOD 和面向 Live 直播的模块,VOD 打包模块将媒体文件分片,并以 F4F 的格式存储,Live 直播打包模块将直播流实时地写入到 F4F 文件当中。HTTP 源模块是标准的 Web Server,存储了 F4F 文件和媒体对应的 F4M 格式的索引文件,索引文件中包含了编码、分辨率以及码率等参数信息。6.分析及小结11 / 11通过研究各种标准组提出的技术

26、规范以及微软、苹果等公司的企业技术方案,我们可以看出基于 HTTP 的码率自适应的实现原理是类似的,主要的区别在于媒体文件格式以及索引文件格式的不同,如表所示。 s在这里我们谈了许多 HAS 的优势,但是目前的技术体系还有许多方面有待完善及改进。首先,上述技术体系都是基于 Client 驱动的模式,依靠 Client 对网络状况及其自身硬件平台的能力情况进行判断,通过解析索引描述文件,最终从头端 Server 中以主动“拉取”的形式获取内容。在直播应用中,终端是需要频繁不断地更新描述文件来获取新的内容的相关信息。如采用 Server 驱动的模式,则不需要对描述文件进行频繁地更新,Server不

27、断获取到最新的内容,并且连续不断地以“推送”的方式向终端发送媒体数据,比较适应于对实时性要求较高的直播应用。其次,上述 HAS 技术体系缺乏质量的监测与控制机制。例如,当一个用户在观看直播频道时进行频道切换,当前时间的 GOP 以及播放器需要的初始化信息需要尽快传送到终端进行播放,但是目前的 HAS 技术体系中没有对重要的 HTTP 包进行加速传输的机制。五、展望未来随着互联网技术的快速推进,利用互联网传输渠道提供视频服务已成为趋势。传统的广电运营商、新兴的视频网站、互联网巨头、彩电厂商以及消费电子类设备商纷纷涌入。所有的参与者都在积极打造各自的新媒体服务平台,以 OTT 的形式将内容分发至电视屏、PC 屏以及手机屏。HAS 技术的出现为面向多终端的新媒体服务平台的建设提供了一个极佳的解决方案,可以预见 HAS 技术将有着极为广阔的发展空间,在三网融合的进程中起到关键的作用。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 学术论文 > 大学论文

本站链接:文库   一言   我酷   合作


客服QQ:2549714901微博号:道客多多官方知乎号:道客多多

经营许可证编号: 粤ICP备2021046453号世界地图

道客多多©版权所有2020-2025营业执照举报