目前，HAS技术的实现方式从标准的类型来看主要有两大类：一类是企业方案，即提供了整体的技术解决方案，如Apple Live Streaming技术、Adobe Dynamic Streaming技术、Microsoft Smooth Streaming技术；另一类是一些国际标准组制定的技术标准，如OIPF的HTTP Adaptive Streaming、MPEG的DASH(Dynamic Adaptive Streaming over HTTP)、IETF的草案（由Apple公司提议的草案）。如图所示。
图 HTTP自适应流媒体技术概览
1. Apple HLS (HTTP Live Streaming)
HTTP Live Streaming是Apple公司的HAS整体解决方案，该方案设计的目标主要是通过普通的Web服务器将直播内容或点播内容推送至Apple的终端设备，如iPhone、iPad以及苹果的台式机。Apple公司的技术规范现已提交至IETF组织讨论，成为正式的 RFC。
HTTP Live Streaming由三部分组成：服务器组件、分发组件和客户端。如图-5所示。
图 HTTP Live Streaming技术框架
首先，编码器接收音视频输入，并采用H.264编码技术，输出MPEG-2 TS流，然后利用切片软件按设定的时间间隔对TS码流进行切割并保存为一个个TS文件。这些TS文件部署在Web服务器上，切片软件同时还创建了包含这些TS文件相关信息的索引文件。索引文件的URL在Web服务器上发布，客户端读取索引文件，然后按顺序向服务器请求媒体文件并无停顿地显示它们。
HTTP Live Streaming方案主要技术特点：
Ø 节目源采用H.264/TS编码格式，可变码率；
使用流切片技术将一个完整的节目切成若干小片，通常是10秒每片，同时使用m3u或m3u8格式生成播放列表文件，索引文件用来指导播放器如何播放文件切片；
Ø 通过HTTP Server分发节目，同时提供合适的缓存；
Ø 能够实现动态自适应码率传输。相对于移动流媒体RTP传输技术，HLS能够根据终端用户带宽的可用性在终端而不是在前端视频服务上，实现对码率的切换。这种实现方式是为用户在无保障的网络上提供好的用户体验。
Ø 索引文件说明了在同一个频道或文件中不同码率节目流的对应性；
Ø 终端根据接收切变文件的时间长度来选择最合适的码率；
Ø 每个切片文件一般是10秒，所以接收设备可以自动适应码率变化；
HTTP Live Streaming支持实时直播和视频点播两种应用场景。
对于实时直播来说，当新的媒体文件被创建时，索引文件也会随之更新，旧的索引文件通常会被删除。更新的索引文件会在连续流中显示一个移动的窗口，这种类型的会话适合连续的直播内容。对于视频点播，媒体文件在整个会话周期内都是固定不变的。索引文件是静态的，只需在媒体开始播放前获取一次，其包含了所有媒体文件的完整列表。
目前，HTTP Live Streaming没有考虑对DRM的完整支持，但它支持内容的加密，通过16位密钥的AES-128加密算法对内容加密，HTTP Live Streaming中仅对如何通过URI获取密钥进行了粗略的定义，并没有说明如何从DRM 密钥服务器中获取密钥。这就说明DRM与HLS之间并不完全兼容。
本文福利， C++音视频学习资料包、技术视频，内容包括（音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）↓↓↓↓↓↓见下面↓↓文章底部↓↓
u 优势
所有iOS设备都默认支持HLS技术，同时Android3.0以上系统也支持播放HLS流。因此HLS技术有着巨大的市场，特别是针对移动设备。HLS为不可靠的开放网络提供了一种有效的码率自适应方案。HLS使用成熟的H.264编解码技术，目前H.264解码芯片提供商有很多。HLS基于TS技术，使得它可以很容易集成到已有的数字电视系统中，许多IPTV DRM方案提供商能够提供相应的解决方案。
u 不足
自适应技术方案只限制在用户端，这种动态方法可能限制某些专业用户希望能够自己对特殊内容传输进行微调和控制；APPLE并没有支持主要浏览器集成HLS，缺乏插件使得利用Web TV收看HLS节目变得困难；HLS主要使用MPEG标准，兼容HLS技术的设备可能需要向MPEG LA支付一定的专利费。HLS中DRM加密采用是端到端整体加密实现，这样降低了系统的灵活性；目前，HLS只能提供一个音轨在一个视频流中。IOS 5能够提供可切换的音轨，但是音轨数量被限制在2个，而在Smooth Streaming或MPEG-DASH中则对音轨的数量没有限制。
2. Adobe HDS (HTTP Dynamic Streaming)
Adobe公司的传统流媒体解决方案RTMP+FLV的组合，在互联网视频行业得到了广泛的应用。针对动态码率自适应的需求，Adobe公司首先在其传统的解决方案上实现了码率自适应，但随后不久Adobe公司也推出了基于HTTP的码率自适应解决方案HTTP Dynamic Streaming，如图所示。
图 HTTP Dynamic Streaming技术框架
Adobe HTTP Dynamic Streaming包含了多个部件来完成内容的准备工作，并通过HTTP将内容传送给终端的Flash Player。
内容准备模块包括了面向VOD和面向Live直播的模块，VOD打包模块将媒体文件分片，并以F4F的格式存储，Live直播打包模块将直播流实时地写入到F4F文件当中。
HTTP源模块是标准的Web Server，存储了F4F文件和媒体对应的F4M格式的索引文件，索引文件中包含了编码、分辨率以及码率等参数信息。
HDS 的文件格式为 FLV/F4V/MP4，索引文件为 f4m，同时支持直播和时移。HDS系统主要由以下几个部分组成：
Ø 一个以XML为基础的索引文件.f4m
Ø 包含MPEG-4编码格式内容的片文件.f4f
Ø 包含切片文件说明信息的索引文件.f4x
HDS支持H.264以及VP6视频编码格式，AAC和MP3音频编码格式。.f4m 文件块索引文件文件包好一个bootstrap，它相对于MPEG-DASH的初始化段，这能够指示终端播放器从哪一个片开始解码。在文件块索引文件中，如果有多种码率可选，播放器能够根据内容回看效果选择最合适的码率。播放器是用Action语言编写，能够运行在Flash或者Adobe AIR框架下。Adobe提供了一个参考视频播放器，称为Open Source Media Framework（OSMF），在互联网上已经有一些flash/java播放器基于这种方式编写，这些播放器基本上是完全定制化播放HDS视频流。
对于内容保护而言，HDS唯一支持的DRM方案是其自身Adobe DRM系统，Flash Access服务器，Flash Access方案是一个很有特点的加扰系统，版权管理中有很灵活的控制权，它能够对保护层进行保护也能够对视频文件切片进行保护。
u 优势
Adobe成功在月在互联网早期发展过程中将其框架作为一种强制插件嵌入到网页中。同时，Flash插件到今天已经有能力自动更新，现在几乎所有的PC都能播放Adobe HDS码流。HDS在Adobe为VOD应用提供了丰富的文档，他们能够为开发送人提供一些参考源代码以支持对方开发有价值的第三方插件。基于HTTP的流的优势是：不需要防火墙开普通web浏览器所需端口以外的任何端口。允许视频切片在浏览器、网关和CDN的缓存，从而显著降低源服务器的负载。
u 不足
Apple目前在Apple产品中不支持Flash。但是对于Android平板电脑和智能手机，Flash的支持非常依靠具体的Android版本，即使是特定Android版本，Flash支持也依赖硬件平台厂家。HDS只支持自己的DRM方案，从Adobe开放出来的文档中也很难看出Flash Access是如何工作的，尤其是直播应用。和Apple HLS一样，HDS码流目前只能提供一个音轨。在改进版的系统中对于点播节目能够提供可替换音轨，但是直播节目不具备这个功能。
3. Microsoft MSS (Microsoft Smooth Streaming)
Smooth Streaming是微软提供的一套HAS解决方案，是IIS的媒体服务扩展，用于支持基于HTTP的自适应串流，终端采用Silverlight技术。MSS 的文件切片格式为 mp4（fragmented-mp4），索引文件为ism/ismc，同时支持直播和时移。
在2010年11月发布的 IIS Media Services 4.0 中，微软引入了一项使 Live Smooth Streaming H.264/AAC 视频动态封装成 Apple HLS 格式的功能，直接提供给 iOS 设备，而不需要再次编码。同时支持直播和点播把1080P全高清视频发送到Silverlight客户端。如图-7所示。
图 Microsoft Smooth Streaming技术框架
微软的Smooth Streaming选择了MPEG-4格式为媒体封装格式，Smooth Streaming将每个分片都用MPEG-4封装成一个MPEG-4的Fragment，但是每个码率对应的内容存储成了一个完整连续的MP4文件，事实上媒体仅仅是做了虚拟的分片。在实际播放过程中，根据终端的请求将每个Fragment独立分发给终端。
MP4文件的基本单位是“BOX”。这些“BOX”中即包含数据也包含元数据。MP4支持在一个文件内容以不同的方式来组织数据和元数据。在大多数媒体场景中，将元数据放在负载数据之前对于播放器的读取时非要有用的，因为播放器可以在播放之前可以更多的知道负载数据信息。然而，不太可能在整个数据流前写入元数据。较少的元数据信息意味着小的数据包头，有利于更快的启动播放器。基于以上理由MP4 文件格式中允许存在一系列小的元数据、负载数据对，而不是一个长的元数据/负载数据对。微软Smooth Streaming存储媒体格式如图所示。
图 Smooth Streaming存储媒体格式
从上图中我们能看到在一个外壳中，文件以文件元数据信息（moov）开始，但是负载带元实际包含在片BOX单元中，在这些BOX中又携带了准确的文件片元数据（moof）和媒体数据（mdat），格式以mfra索引BOX结束。
微软在MP4 ISO媒体文件描述格式的基础上自定义了BOX组织数据结构和BOX信息。为了区分Smooth Streaming文件和标准的“vanilla”MP4文件格式，微软使用了新的文件扩展：*.ismv(视频和音频)和*.isma音频。
当一个播放器客户端向IIS服务器请求一个视频时间片段时，服务器会在MP4文件中寻找合适的文件片，并将其取出封装完成后传输给客户端。文件片经过封装后可以有效提高传输效率。微软Smooth Streaming传输媒体格式如图所示。
图 Smooth Streaming传输媒体格式
Smooth Streaming终端基于Silverlight进行实现，Silverlight可完成MPEG-4文件格式的解析、HTTP下载以及码率的切换。在Smooth Streaming的设计方案中，微软使用了更加复杂的设计。视频文件不需要被切成无数小的文件片，而只是在传输时按照文件片的方式传输，而这些文件片实际上来自MP4文件中的GOP片段。这样的设计需要在服务器端和客户端实现以下两点改变：服务器必须能将URL转换成在MP4文件中的准确的偏移范围；客户端能够支持更加开放的请求格式；
客户端播放器首先从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文件封装后发送给客户端。这个部分的设计对于整个传输设计是至关重要的。客户端下载的内容会在网络中自动缓存，如果其他的客户端请求了同样的内容便会从缓存中获取这样就大大节省了服务端的压力。
u 优势
Smooth Streaming在一个码流中能够支持多声道和多个主题。Smooth Streaming已经将DRM很好的集成到其中。虽然，微软也有自己的PlayReady解决方案，它也明确的支持其他的DRM厂家与Smooth Streaming的集成。在网页媒体领域，Smooth Streaming在高清直播中获得了很好的图像质量，与以flash技术为基础的视频网站相比，Silverlight能够根据客户端的解码能力去选择合适的节目码率进而保证节目的流畅。
u 不足
微软的Smooth Streaming方案非常详细，所以部署起来很费时间，结果是该方案不如HLS那样容易被接受。尽管Smooth Streaming以Web媒体为目标，但是客户端必须嵌入Silverlight，及时是IE浏览器也必须安装额外的插件。像HLS一样，Smooth Streaming不能依靠网络中心服务器来管理带宽，这些工作必须依靠客户端设备。
原文链接：流媒体技术介绍（中篇） - 资料 - 我爱音视频网 - 构建全国最权威的音视频技术交流分享论坛
本文福利， C++音视频学习资料包、技术视频，内容包括（音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）↓↓↓↓↓↓见下面↓↓文章底部↓↓