简介
如果你对以下任何一项感兴趣
- iPhone, iPod touch, iPad的音视频流
- 在没有特殊服务器软件的情况下传输直播事件
- 在有加密、验证需求时发送视频
那么你应该学习HTTP流媒体技术。
HTTP流媒体能够让你通过HTTP，从普通网络服务器，发送音视频到iOS设备（包括iPhone, iPad, iPod touch和Apple TV）和桌面电脑（Mac OS X）用以播放。
HTTP流媒体同时支持直播和回放预录制内容。HTTP流媒体支持多种比特率之间的切换, 同时客户端也可以根据网络带宽自动切换。 HTTP
同时提供通过HTTPS进行媒体加密和用户验证，使得发布者能够保护他们的成果。
所有运行iOS3.0及更新版本的设备都内置一个支持HTTP流媒体的客户端。 Safari浏览器能够在iPad和桌面电脑上的网页中播放HTTP直播流，或者在小屏幕iOS设备（例如iPhone和iPod）上为HTTP视频流加载一个全屏媒体播放器。 Apple TV 2以及更高的版本的Apple TV则包含了一个HTTP流媒体客户端。
重要：通过移动蜂窝网络发送大量视频或音频数据的iPhone和iPad应用被要求使用HTTP流媒体。参见应用要求
Safari会将含有<video>标签的资源以HTTP流媒体本地播放。 Mac OS
X开发者可以使用QTKit和AVFoundation框架来创建播放HTTP流媒体的桌面应用。
iOS开发者可以使用MediaPlayer和AVFoundation框架来创建iOS应用。
重要：尽可能使用
<video>标签来嵌入HTTP流媒体，而仅在标记备用内容时使用<object>或<embed>标签
由于使用HTTP协议，这种流媒体被几乎所有边际服务器、媒体分发商、缓存系统、路由器和防火墙支持自动支持
备注：许多现有的流媒体服务要求使用特殊服务器以将内容分发给终端用户。这些服务器需要特殊的技能来建设和维护，并且大规模部署这类服务器会非常昂贵。HTTP流媒体通过标准HTTP协议传送媒体来避免这些开销。另外，HTTP流媒体是为了与大规模操作的媒体分发网络无缝衔接工作而设计的。
HTTP流媒体规范是一份IETF互联网草案。草案的链接请见下面的“另见”一节
概览
HTTP流媒体是一种通过HTTP协议将音频和视频从网络服务器传送到iOS设备或桌面电脑客户端应用上的方式。
你无需特殊的服务器软件即可发送视频和音频
你可以在一个普通WEB服务器上提供HTTP流媒体的音视频服务。客户端软件可以是Safari浏览器或者你为iOS或者Mac OS X开发的应用。
HTTP流媒体，以一系列叫做媒体段文件的长度10秒左右的小文件的形式，传送音频和视频。索引文件，或者叫播放列表，将媒体段文件的URL提供给客户端。播放列表可以被周期性地更新，以适应不断产生媒体片段的直播。你可以向网页中嵌入一个指向播放列表的链接或者将其发送给你开发的应用。
你可以按需发送视频或者直播流（加密可选）
对于已经已经录制好的媒体，苹果提供一个可以将MPEG-4及H.264编码的QuickTime影片，或者AAC、MP3编码的音频文件，制作成媒体段文件和播放列表的免费工具。这些播放列表和媒体段可以用于播放视频或者广播流。
对于直播流，苹果提供一个可以将MPEG-2传输流（包含H.264视频、ACC音频或者MP3音频）制作成段文件和播放列表的免费工具。现在有一系列的硬件和软件编码器能够实时创建搭载了MPEG-4视频和AAC音频的MPEG-2传输流。
这些工具可以被指定加密你的媒体并生成解密密钥。你可以为你的所有流使用单一密钥、为每个流分配不同密钥或者一组随机生成的随间隔变换的密钥。密钥会被一个可以设置为周期性更改的初始化向量保护。
先决条件
你应该对一般的音频和视频文件格式有大概的了解，并且熟悉网络服务器和浏览器是如何工作的。
另见
- iOS Human Interface Guidelines——如何为iOS设备设计网页内容
- HTTP Live Streaming protocol——HTTP流媒体规格的IETF网络草案
- HTTP Live Streaming Resources——帮助你开始的信息和工具集
- MPEG-2 Stream Encryption Format for HTTP Live Streaming一个关于加密格式的详细描述
HTTP串流结构
HTTP流媒体允许你从普通网络服务器传送实时或者预先录制的音频或视频到任何运行iOS3.0及更高版本的设备（包括iPad和Apple TV）或者任何安装了Safari 4.0或更高版本的电脑。串流同时包含有加密和认证支持。
概览
概念上，HTTP流媒体由三部分组成：服务器组件，分发组件，客户端软件。
服务器组件负责取得媒体的输入流并且将其编码，转换成适合传输的格式，然后为分发准备转换好的媒体数据。
分发组件由标准网络服务器组成。它们负责接收客户端请求并向客户端分发准备好的媒体数据和关联资源。对于大规模的分发，边际网络或者其他内容分发网络也可以被使用。
客户端软件负责确定需要请求的媒体数据，下载这些资源，然后将其重新组合以保证能够展示给用户完整的串流。客户端软件包含在iOS 3.0及更高版本和安装了Safari 4.0及更高版本的电脑上。
在典型的配置中，硬件编码器接受音频-视频输入，编码为H.264视频和AAC音频，然后以MPEG-2
传输流输出。这个传输流将会被流分段软件分为一系列的小媒体文件。这些媒体文件会被放置在网络服务器上。分段器同时创建并维护一个包含这些媒体文件列表的索引。这份索引的链接会在网络服务器上被发布。客户端软件读取索引，然后按顺序请求列表上的媒体文件然后不间断的播放媒体片段。
一个简单的HTTP串流配置如图1-1。
图1-1
输入可以是实时的或者是一个预先录制好的源。典型的编码是MPEG-4（H.264视频和AAC音频），并由已有的硬件封装为MPEG-2传输流。该MPEG-2传输流之后会被分成若干段并被保存为一系列的.ts媒体文件。这项工作可以借助例如Apple
stream segmenter这类软件完成。
仅包含音频的串流可以是一系列的MPEG基本音频文件。编码包括含ADTS头的AAC、MP3和AC-3。
分段器同时会创建一个索引文件。索引文件包含一个媒体文件列表，同时还保存有元数据。这份索引是一个.M3U8播放列表文件。索引文件的链接经由客户端访问，之后客户端会按序请求被索引的文件。
服务器组件
服务器需要有一个媒体编码器（可以是现有的硬件），以及能够将编码过的媒体文件分歌声段并存储为文件的方法。这种方法可以是如Apple提供的媒体流分段器软件，或者一个完整的第三方解决方案。
媒体编码器
媒体编码器从音频-视频设备接收实时信号，将媒体编码并为传输做好包装。编码应该被设定为客户端设备支持的格式，如H.264视频和HE-AAC音频。现阶段支持的传输格式为MPEG-2视频-音频传输流，及仅音频的MPEG简单流。
编码器通过本地网络将编码过的媒体以MPEG-2传输流发送给流分段器。MPEG-2传输流不应与MPEG-2视频压缩格式相混淆。传输流是可以使用多种不同压缩格式包装格式。视频技术和音频技术列出了支持的压缩格式
重要： 视频编码器不应该在编码中更改诸如视频尺寸或编译码器类型等串流设置。如果更改设置不可避免，则务必只在段的边界时更改设置，并且比如为下一个段设置
EXT-X-DISCONTINUITY标签。
流分段器
流分段器是一个从本地网络读取传输流并将其分成一系列等长的小媒体文件的软件。尽管每个段是独立的文件，这个视频文件是从一个可以被无缝重建为一个持续的流被建立的。
分段器同时会创建一个包含每个独立媒体文件的索引。每当分段器完成一个新媒体文件的创建，索引文件就会被更新。索引文件用于追踪媒体文件的的可用性和存放位置。分段器在分段流程中同时可以对每个媒体段进行加密并创建一个密钥文件。
媒体段文件被保存为.ts文件（MPEG-2传输流文件）。索引文件被保存为.M3U8播放列表。
文件分段器
如果你已经有了使用被支持的编码器编码过的媒体文件，此时可以使用文件分段器将其包装为MPEG-2传输流并分成等长的小段。文件分段器允许你使用现有的音频和视频文件库通过HTTP流媒体来传输视频。文件分段器所作的任务与流分段器相同，只是输入从流变为了文件。
媒体段文件
媒体段文件通常基于编码器的输入由流分段器产生，包含一系列含有MPEG-2传输流小段的.ts文件。该传输流编码为H.264视频和AAC/MP3/AC-3音频。对于仅音频的广播，分段器可以创建简单音频流，编码包括带ADTS头的AAC、MP3和AC-3。
索引文件（播放列表）
索引文件通常由流分段器和文件分段器产生，以.M3U8播放列表格式存储。M3U8是一个用于MP3播放列表的.m3u的扩展格式。
备注：由于索引文件是
.m3u格式的扩展，以及系统同时支持.mp3音频媒体文件，客户端软件同时也可能兼容用于网络广播串流的普通MP3播放列表。
下面是一个.M3U8格式索引文件的简单例子。例子中分段器从一个完整的流创建了三个未加密的10秒长度的媒体文件。
#EXT-X-VERSION:3
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:1
# Old-style integer duration; avoid for newer clients.
#EXTINF:10,
http://media.example.com/segment0.ts
# New-style floating-point duration; use for modern clients.
#EXTINF:10.0,
http://media.example.com/segment1.ts
#EXTINF:9.5,
http://media.example.com/segment2.ts
#EXT-X-ENDLIST
为了保证最大的精确度，当你向支持版本3及更高的协议的客户端传送播放列表时应该将所有持续时间设置为浮点数（较老版本客户端仅支持整形变量）。当你使用浮点数时，必须执行协议版本，否则应该遵守协议版本1。
备注：你可以使用Apple提供的分段器并以MPEG-4视频或者AAC/MP3音频作为源来产生一系列示例播放列表。详情请见媒体分段器。
索引文件同时也可能包含加密密钥文件和为不同带宽准备的其他索引文件的链接。关于索引文件格式的详情，请参见IETF的互联网草案：HTTP Live Streaming specification。
索引文件通常由创建媒体段文件的分段器同时生成。或者只要符合已发布的规范，即可独立创建.M3U8文件和媒体段文件。例如对于仅音频的广播，你可以通过文本编辑器创建.M3U8文件并李处一系列现存的.MP3文件。
分发组件
分发系统是一个通过HTTP向客户端媒体文件和索引文件的网络服务器或者网络缓存系统。传输内容不需要定制化的服务器模块，并且不需要对服务器进行大量设置。
推荐配置一般仅限于指定.M3U8和.MP3文件的MIME类型关联。
详情请见部署HTTP流媒体。
客户端组件
客户端软件基于标志了流的链接来获取索引文件。索引文件按序表明有效媒体文件位置、解密密钥和是否有其他的有效的源可供使用。对于选定的串流，客户端下载按队列下载每个可用的媒体文件。每个文件包含串流的连续段。当客户端下载了足够的数据之后会将重新组合的流播放给用户。
客户端有责任获取解密密钥、认证或为认证提供用户交互界面以及按需解密媒体文件。
这个流程会持续知道客户端在索引文件中检测到了#EXT-X-ENDLIST标签。如果#EXT-X-ENDLIST标签没有出现，这个索引文件是一个持续广播的一部分。在持续广播中，客户端会周期性加载更新版本的索引文件。之后会在更新过的索引文件中寻找心的媒体文件和解密密钥并将这些链接加入下载队列。
使用HTTP流媒体
下载工具
目前有许多已有的工具帮助你搭建一个HTTP流媒体服务。这些工具包括一个媒体流分段器、一个媒体文件分段器、一个流验证器、一个id3标签生成器和一个播放列表生成器。
这些工具时常会有更新，所以你应该在Apple开发者网站下载HTTP流媒体工具的最新版本。如果你是iOS开发者计划的成员你就可以获取这些软件。可以通过登录到developer.apple.com并使用搜索功能以获取相应软件。
媒体流分段器
mediastreamsegmenter命令行工具接受MPEG-2传输流为输入并生成一系列适合HTTP流媒体使用的等长的文件。这个工具同时可以生成索引文件（或者叫播放列表），加密媒体，生成解密密钥(注：此处原文为encryption
keys，疑应为decryption
keys)，优化文件以节省开销，和生成多个供选择的流的必要文件。详细信息请先确认安装了工具，然后使用man mediastreamsegmenter命令。
使用示例：mediastreamsegmenter -s 3 -D -f /Library/WebServer/Documents/stream 239.4.1.5:20103
这个示例从239.4.1.5:20103捕获实时流并从中生成媒体段文件和索引文件。索引文件包含当前的三个媒体段文件的列表(-s 3)。媒体段文件在使用了-D参数后会被删除。索引文件和媒体段文件会被存储在路径/Library/WebServer/Documents/stream中。
媒体文件分段器
mediafilesegmenter命令行工具接受编码过的媒体文件作为输入，将其转换为MPEG-2传输流并生成一系列适合HTTP流媒体使用的等长的文件。媒体文件分段器同时也可以生成索引文件和解密密钥。文件分段器使用方式与流分段器很相似，只是接受的输入是现有文件而不是从编码器生成的流。详情请使用man mediafilesegmenter命令。
媒体流验证器
variantplaylistcreator命令行工具会使用mediafilesegmenter的输出创建一个主索引文件（或播放列表）。这个索引文件列出了其他可选比特率的索引文件。mediafilesegmenter必须使用-generate-variant-playlist参数以生成变体播放列表生成器所需的输出。详情请使用man variantplaylistcreator命令。
媒体标签生成器
id3taggenerator命令行工具生成ID3元数据标签。这些标签可以写到文件中或插入传输中的视频流分段中。详情请请见Adding
Timed Metadata
会话类型
HTTP流媒体协议支持两种会话：事件（实时广播）和视频点播（VOD）。
VOD会话
对于VOD对话，媒体文件在整个播放时间中是持续可用的。索引文件是固定的并且包含从播放开始是的完整的文件列表。这种会话允许客户端访问整个程序。
VOD也可以用于发送“罐装”的媒体。HTTP流媒体为VOD提供了逐步下载的优点，例如支持媒体加密和在不同的比特率的流之间切换以调整连接速度。（QuickTime也通过逐步下载支持多数据速率但是QuickTime电影不支持播放中动态切换不同的速率）。
实时会话
实时会话（活动——可以被表示为一个完整的活动记录或者一个包含用户可以查看的有限时间长度的滑动窗口。
对于实时会话，当媒体文件被创建并且变成可用时，索引文件会被更新。新的索引文件列出新的媒体文件。旧的媒体文件可以从索引中移除并废弃，表示一个持续的流的移动窗口。这种类型的会话适合持续的广播。或者可以仅仅向索引文件中加入新的媒体晚间，这种会话可以在活动完成后轻松的被转换为VOD。
创建一个即时支持VOD的活动的广播是可行的。若要将实时广播转换成VOD，不要从服务器移除旧媒体文件及其在索引文件中的链接地址。在活动结束后在索引文件中加入#EXT-X-ENDLIST标签。这允许晚一些进入直播的客户端仍然能够看到完整的活动，同时也能无需其他工作即可存档重播。
如果你的播放列表包含EXT-X-PLAYLIST-TYPE标签，你应该将值从EVENT转换为VOD。
内容保护
含流段的媒体文件可以被单独加密。当使用加密时，相应的密钥文件会出现在索引文件中，以使客户机可以检索该密钥用于解密。
当一个密钥文件中在索引文件中列出，密钥文件包含必须用于解密在索引文件中列出的后续媒体文件的密钥。目前，HTTP实时流支持使用16字节密钥的AES-128加密。密钥文件的格式是用二进制格式这16八位位组的填充阵列。
Apple提供的媒体流分段器提供三种加密和支持加密的配置模式。
第一种模式允许您指定磁盘上现有的密钥文件的路径。在这种模式下，分段器将现有密钥文件的URL插入在索引文件中。它使用该密钥加密所有媒体文件。
第二种模式指示分段器生成一个随机密钥文件，并将其保存在指定的位置，并在索引文件中引用它。所有的媒体文件都采用这种随机产生的密钥加密。
第三模式指示分段器为每n个媒体段产生一个新的随机密钥文件，将其保存在一个指定的位置，并在索引文件中引用它。这种模式被称为密钥旋转。每个组的n个文件使用不同的密钥加密。
备注：所有媒体文件可以使用相同的密钥进行加密，或每隔一段时间申请神的密钥。理论极限是每媒体文件中的一个密钥，但由于每个媒体密钥增加了一个文件请求和传输请求用于呈现随后的媒体段，周期性更新密钥可以比每段都更新密钥更小的影响系统性能。
你可以使用HTTP或HTTPS提供密钥文件。你也可以选择保护使用自己的基于会话的认证方案密钥文件的交付。有关详细信息，请参阅Serving Key Files Securely Over HTTPS。
密钥文件需要的初始化向量（IV）以解密加密媒体。IV可以像密钥一样周期性改变。
缓存和分发协议
HTTPS通常用于提供密钥文件。它也可用于递送媒体段文件和索引文件，但当重视扩展性时不推荐这样做，因为HTTPS请求经常绕过web服务器缓存，导致所有内容请求被导向服务器，这与边缘网络分发系统的初衷相悖。
正是由于这个原因，确保您使用的任何内容分发网络了解到，.M3U8索引文件被缓存的时间不会超过一个为直播准备的媒体段的持续时间。其索引文件是动态变化的。
备用流
一个主索引文件可能会引用内容的备用流。引用可以用于支持不同质量级别不同的带宽或设备下的同一内容的多个流的递送。 HTTP实时流支持动态如果可用带宽变化流之间的切换。客户端软件使用启发式算法以确定画面切花的合适时间。目前，这些启发式基于在测量网络吞吐量的最新趋势。
主索引文件指向媒体备用流，包括其他索引文件专门标记列表，如图2-1所示。
主索引文件和辅助索引文件都以.M3U8播放列表格式存储。主索引文件只需下载一次，但对于直播节目备用索引文件需要定期重新加载。在主索引文件中列出的第一个备用流第一个被使。在此之后，客户端可以根据可用带宽选择备用流。
注意，客户端可能会选择在任何时间改变到备用流，比如当移动设备进入或离开一个WiFi热点。所有的候补应该使用相同的音频，让流之间平滑过渡。
你可以使用variantplaylistcreator创建一组备用流。也可以在使用mediafilesegmentertool或mediastreamsegmenter工具时指定-generate-variant-playlist选项。详见下载工具
带使用备用流是，牢记以下注意事项是非常重要的：
- 该变体的播放列表的第一个条目，当用户加入该流时被播放，并用作测试的一部分，以确定哪些流是最合适的。其他条目的顺序是无关紧要的。
- 如果可能的话，编码变体足以提供在大范围的连接速度最优质的流。例如，编码在150 kbps的，350 kbps的，550 kbps的，900 kbps的1500 kbps的变种。
- 如果可能的话，在变体播放列表和独立的.M3U8播放列表文件中使用相对路径名。
- 备用流的视频横纵比必须完全一样，但备用流可以有不同的像素尺寸，只要它们具有相同的纵横比。例如，同为4：3的宽高比可以有400×300和800×600的尺寸。
- 包含在
EXT-X-STREAM-INF的RESOLUTION域应帮助客户端选择合适的流。 - 如果你是一个iOS应用程序开发人员，你可以查询用户的设备，以确定的初始连接是网络或WiFi，并选择合适的主索引文件。 当媒体流被播放时为确保用户具有良好的体验，不论初始的网络连接，你应该有多于一个的由不用的备用索引文件组成的主索引文件。 蜂窝网络播放列表推荐使用150K流。 Wi-Fi网络播放列表推荐使用240K或440K流。
备注：关于确定iOS设备的网络连接类型的细节，请参考实例代码
-
当你指定流变体的比特率时，
BANDWIDTH参数紧密地匹配由一个给定流所需的实际带宽是很重要的。如果实际的带宽要求与BANDWIDTH参数显著不同，数据流的自动切换可能无法平稳甚至正确的被执行。
蜂窝网络下的视频
当您发送视频到移动设备，如iPhone或iPad，客户端的互联网连接可能在任何时间移动到或离开蜂窝网络。
HTTP流媒体允许客户端在动态网络带宽的变化中选择备用流，以当设备在蜂窝网络和WiFi间切换时提供最佳的流，例如，3G和EDGE连接之间切换。这是渐进式下载的一个显著优势。
我们强烈建议您使用HTTP流媒体提供视频给所有的蜂窝网络设备，甚至是视频点播，为观众在变化的条件下尽可能提供最佳的体验。
此外，你应该为蜂窝网络的客户端提供在64 Kbps或更少较慢的数据连接使用的备用流。如果你不能在64Kbps或更低速率下提供可接受质量的视频，您应该提供一个仅音频流，或者用静止图像的音频。
为蜂窝网络准备的链接分辨率推荐为400x224(16:9)或400x300(4:3)（参见Preparing Media for Delivery to iOS-Based Devices）。
应用程序需求
警告：在App Store中提交分发的应用必须符合下列要求
如果您的应用程序通过蜂窝网络传送视频，并且视频持续超过10分钟或在5分钟内使用超过5MB数据，你必须使用HTTP实时流。 （渐进式下载可用于更小的片段）。
如果您的应用程序通过蜂窝网络使用HTTP流媒体，您需要在64 Kbps或较低的带宽（低带宽流可能仅音频或静止图像音频）提供至少一个流。
这些要求适用于在App Store提交分发上使用苹果产品的iOS应用。不符合要求的应用程序基于苹果公司的决定可能会被拒绝或删除。
冗余流
如果您的播放列表包含备用流，它们不仅可以用于带宽或设备交替，也可以用于故障回退。从iOS 3.1开始，如果客户端无法加载一个流的索引文件（例如由于404错误），客户端尝试切换到备用流。
在对一个索引加载失败的情况下，客户端会选择网络连接支持的最高带宽的备用流。如果有多个相同的带宽的备用流，客户端按播放列表中列出的顺序选择。
您可以使用此功能来提供冗余流，使即使发生严重的局部故障，如服务器崩溃或内容分发节点下线的情况媒体依然能够送达到客户端。
为了支持冗余流，通常会创建一个流或多个备用带宽数据流，并生成一个播放列表文件。然后在独立的服务器或内容分发服务上创建一个平行流或组流。将备用流加入播放列表以保证各个带宽的备用流在主要流后面列出。例如，如果主流来自于服务器ALPHA，备份流来自服务器BETA，您的播放列表文件可能是这个样子：
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000, RESOLUTION=720x480
http://ALPHA.mycompany.com/lo/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000, RESOLUTION=720x480
http://BETA.mycompany.com/lo/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000, RESOLUTION=1920x1080
http://ALPHA.mycompany.com/md/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000, RESOLUTION=1920x1080
http://BETA.mycompany.com/md/prog_index.m3u8
注意，备用流和主要流在播放列表中混合存储。备用流列在对应带宽的主要流的后面。
你不被局限于单一的备用流集。例如在上面的例子中，ALPHA和BETA可接着GAMMA。同样的，你不需要提供一个完整的并行组流。例如可以在备用服务器上提供一个单一的低带宽流。
添加定时的元数据
您可以各种元数据添加到媒体流段。例如，您可以将专辑封面，艺术家的名字和歌曲标题添加到音频流。另举一个例子，您可以将当前击球手的名字和统计信息添加到棒球比赛的视频中。
如果仅音频流包括图像作为元数据，苹果客户端软件会自动显示它。目前，由苹果公司提供的客户端软件会自动显示的唯一元数据是伴随纯音频流的静止图像。
但是如果你正在写自己的客户端软件，无论是使用MPMoviePlayerController或AVPlayerItem，都可以使用timedMetaData属性访问流的元数据。
如果你正在写自己的分割器，可以阅读有关HTTP流媒体中的定时元数据。
如果您在使用苹果的工具，您可以使用流分段或文件分段器的-F命令行选项指定元数据以添加定时的元数据。指定的元数据源可以是ID3格式的文件或图像文件（JPEG或PNG）。元数据中指定这种方式会自动插入到每一个媒体片段。
它被一个给定的时间偏移并插入到媒体流，所以它被称为定时元数据。定时元数据可以选择性地被插入一个给定的时间后的所有的段。
若要添加定时元数据到实时流，使用id3taggenerator工具，其输出设置为流分段。该工具生成ID3元数据，并将其列入输出流中的流分段。
标签生成器可通过脚本运行，例如，在指定的时间以指定的间隔插入元数据。新的定时元数据会自动替换任何现有的元数据。
一旦元数据被插入到一媒体段，它便会一直存在。例如如果实况广播在视频点播中被重新利用，它会保留原始广播期间插入的任何元数据。
加入定时元数据使用文件分段创建流是略微复杂一些。
- 首先生成元数据样例。你可以生成使用id3taggenerator命令行工具生成ID3元数据并将输出保存到文件。
-
接下来创建一个元数据宏文件——一个包含数据插入时间、元数据类型和元数据路径及文件名信息的文本文件。
例如下列的元数据宏文件会在1.2秒时插入一副图片，在10秒时插入ID3标签1.2 picture /meta/images/picture.jpg 10 id3 /meta/id3/title.id3 -
最后当你调用媒体文件分段器时，使用-M选项指定元数据宏文件。
更多细节请参考mediastreamsegmenter, mediafilesegmenter, 和id3taggenerator的man页面。
添加隐藏式字幕
HTTP实时流支持流内的字幕。如果您使用的是流分段器，就需要将CEA-608字幕按ATSC A /72添加到MPEG-2传输流（在主视频基本流中）。如果你使用的文件分割器，你应该将媒体封装在QuickTime影片文件中，并添加字幕轨道（'CLCP'）。如果你正在编写一个应用程序，AVFoundation框架支持播放字幕。
直播还支持多种字幕和网络视频文本轨道（WebVTT插入）格式的隐藏字幕轨道。表2-1中的示例显示了在主播放列表中的两个字幕轨道。
表2-1
#EXTM3U
#EXT-X-MEDIA:TYPE=CLOSED-CAPTIONS,GROUP-ID="cc",NAME="CC1",LANGUAGE="en",DEFAULT=YES,AUTOSELECT=YES,INSTREAM-ID="CC1"
#EXT-X-MEDIA:TYPE=CLOSED-CAPTIONS,GROUP-ID="cc",NAME="CC2",LANGUAGE="sp",AUTOSELECT=YES,INSTREAM-ID="CC2"
#EXT-X-STREAM-INF:BANDWIDTH=1000000,SUBTITLES="subs",CLOSED-CAPTIONS="cc"
x.m3u8
在编码过程中，WebVTT文件像音频和视频媒体一样被分成段。由此产生的媒体播放列表包括段持续时间与相关的视频正确的点同步文本。
直播字幕的高级功能包括语义元数据，CSS样式，和简单的动画。更多信息和WebVTT的实现参考WWDC 2012: What's New in HTTP Live Streaming和WebVTT: The Web Video Text Tracks Format specification.
准备传输至iOS设备的媒体
基于IOS的设备中使用的数据流的建议的编码器设置示下列四个表所示。对于实时流，这些设置应该在您的硬件或软件编码器可用。如果要从主文件重新编码为视频点播，你可以使用一个视频编辑工具，如Compressor。
为文件分段的文件格式可以是一个使用指定的编码的QuickTime电影，MPEG-4视频，或MP3音频。
流分段器所分个的流格式必须是MPEG基本音频和视频流，打包成MPEG-2传输流，并使用以下的编码。音频技术和视频技术的列表支持压缩格式。
- H.264压缩编码
- H.264 Baseline 3.0: 所有设备
- H.264 Baseline 3.1: iPhone 3G或更高, and 第二代iPod touch或更高.
- H.264 Main profile 3.1: iPad（所有版本）, Apple TV 2 或更高, iPhone 4 或更高.
- H.264 Main Profile 4.0: Apple TV 3 或更高, iPad 2 或更高, and iPhone 4S 或更高
- H.264 High Profile 4.0: Apple TV 3 或更高, iPad 2 或更高, and iPhone 4S 或更高.
- H.264 High Profile 4.1: iPad 2 或更高 and iPhone 4S 或更高.
- 200kbps以下的速率推荐10fps帧率。300kbps以下的速率推荐12到15fps帧率。其他的速率推荐29.97fps帧率。
- 音频用以下的一种编码
- HE-AAC or AAC-LC, stereo
- MP3 (MPEG-1 Audio Layer 3), stereo
- 在使用支持AC-3输入的环绕式音频接收器或电视时，可以选择为Apple TV或AirPlay传输至Apple TV准备AC-3音轨。
- 在所有情况下推荐最小为22.05kHz的采样率和40kbps的比特率，使用Wi-Fi时推荐更高的采样率和比特率。
表2-1 最低主编码器设置，16：9横纵比
| 连接种类 | 像素 | 总比特率 | 视频比特率 | 关键帧 |
|---|---|---|---|---|
| 蜂窝网络 | 400 x 224 | 64 kbps | 仅音频 | 无 |
| 蜂窝网络 | 400 x 224 | 150 kbps | 110 kbps | 30 |
| 蜂窝网络 | 400 x 224 | 240 kbps | 200 kbps | 45 |
| 蜂窝网络 | 400 x 224 | 440 kbps | 400 kbps | 90 |
| WiFi | 640 x 360 | 640 kbps | 600 kbps | 90 |
表2-2 最低主编码器设置，4：3横纵比
| 连接种类 | 像素 | 总比特率 | 视频比特率 | 关键帧 |
|---|---|---|---|---|
| 蜂窝网络 | 400 x 300 | 64 kbps | 仅音频 | 无 |
| 蜂窝网络 | 400 x 300 | 150 kbps | 110 kbps | 30 |
| 蜂窝网络 | 400 x 300 | 240 kbps | 200 kbps | 45 |
| 蜂窝网络 | 400 x 300 | 440 kbps | 400 kbps | 90 |
| WiFi | 640 x 480 | 640 kbps | 600 kbps | 90 |
表2-3 扩展主编码器设置，16：9横纵比
| 连接种类 | 像素 | 总比特率 | 视频比特率 | 关键帧 |
|---|---|---|---|---|
| WiFi | 640 x 360 | 1240 kbps | 1200 kbps | 90 |
| WiFi | 960 x 540 | 1840 kbps | 1800 kbps | 90 |
| WiFi | 1280 x 720 | 2540 kbps | 2500 kbps | 90 |
| WiFi | 1280 x 720 | 4540 kbps | 4500 kbps | 90 |
表2-4 扩展主编码器设置，4：3横纵比
| 连接种类 | 像素 | 总比特率 | 视频比特率 | 关键帧 |
|---|---|---|---|---|
| WiFi | 640 x 480 | 1240 kbps | 1200 kbps | 90 |
| WiFi | 960 x 720 | 1840 kbps | 1800 kbps | 90 |
| WiFi | 960 x 720 | 2540 kbps | 2500 kbps | 90 |
| WiFi | 1280 x 960 | 4540 kbps | 4500 kbps | 90 |
表2-5 扩展高级编码器设置，16：9横纵比
| 连接种类 | 像素 | 总比特率 | 视频比特率 | 关键帧 |
|---|---|---|---|---|
| WiFi | 1920 x 1080 | 12000 kbps | 11000 kbps | 90 |
| WiFi | 1920 x 1080 | 25000 kbps | 24000 kbps | 90 |
| WiFi | 1920 x 1080 | 40000 kbps | 39000 kbps | 90 |
样例流
在Apple开发者网站上有一系列供测试用的HTTP流。这些样例展示了.M3U8索引文件、.ts媒体段文件的合适格式。这些流可以在HTTP Live Streaming Resources被找到。
部署HTTP流媒体
要实际部署HTTP实时流，你需要创建一个浏览器的HTML网页或客户端应用程序充当接收器。您还需要使用Web服务器和一种方式将实时流编码为MPEG-2传输流或从源文件制作的H.264文件和AAC编码的MP3或MPEG-4媒体。
您可以使用苹果提供的工具来分割流或媒体文件，并生成索引文件和变异的播放列表（见下载工具）。
您应该使用苹果公司提供的流媒体服务验证您的流，以确保它们与HTTP实时流完全兼容。
您可能要加密数据流，在这种情况下，你可能还需要通过HTTPS安全提供加密密钥文件，这样只有您预期的客户端可以解密。
创建HTML页面
最简单分发HTTP实时流媒体的方式是创建一个包含<video>标签的的HTML5页面，.M3U8播放列表文件作为视频源。一个例子在下文列出。
<html>
<head>
<title>HTTP Live Streaming Example</title>
</head>
<body>
<video
src="http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8"
height="300" width="400"
>
</video>
</body>
</html>
对于不支持HTML5视频元素，或不支持HTTP实时流的浏览器，您可以在<video>和</video>之间包含后备代码。例如，您可能回落到渐进式下载影片或使用QuickTime插件的RTSP流。见Safari浏览器HTML5音频和视频指南的例子。
设置网络服务器
HTTP实时流可以从一个普通的Web服务器提供服务;无需特殊配置，除了被他们的文件扩展名关联送达的MIME类型的文件。
配置以下MIME类型HTTP实时流：
| 文件扩展名 | MIME类型 |
|---|---|
| .M3U8 | application/x-mpegURL 或 vnd.apple.mpegURL |
| .ts | video/MP2T |
如果你的Web服务器限制于MIME类型，您可以提供MIME属性为audio/mpegURL的.m3u文件以保证兼容性。
索引文件可以是长期的，也可以频繁地重新下载，但它们是文本文件，并可以非常有效地压缩。您可以通过启用即时的.M3U8索引文件.GZIP压缩降低服务器开销;在HTTP实时流客户端会自动解压压缩索引文件。
有时可能需要缩短.M3U8文件的TTL值，以实现对下游web缓存适当缓存行为，因为这些文件在实况广播经常覆盖，并且对于每个下载请求应下载最新的版本。具体建议内容请与服务提供商确认。对于VOD，索引文件是静态的，只需下载一次，所以缓存是不是一个因素。
使你的流生效
mediastreamvalidator工具是用于验证HTTP实时流流和服务器的命令行实用程序（详见下载工具）。
媒体流验证模拟的HTTP实时流媒体会话，并验证索引文件和媒体段符合HTTP实时流规范。它会执行几项检查，以确保可靠的数据流。如果发现任何错误或问题时，会显示详细的诊断报告。
你应该总是在提供一个新的流或备用流前运行验证器。
媒体流验证显示您提供流的列表，然后为每个数据流的时序结果。（这可能需要几分钟的时间来计算实际时间）下面是一个验证器的输出。
$ mediastreamvalidator -d iphone http://devimages.apple.com/iphone/samples/bipbop/gear3/prog_index.m3u8
mediastreamvalidator: Beta Version 1.1(130423)
Validating http://devimages.apple.com/iphone/samples/bipbop/gear3/prog_index.m3u8
--------------------------------------------------------------------------------
http://devimages.apple.com/iphone/samples/bipbop/gear3/prog_index.m3u8
--------------------------------------------------------------------------------
Playlist Syntax: OK
Segments: OK
Average segment duration: 9.91 seconds
Segment bitrate: Average: 509.56 kbits/sec, Max: 840.74 kbits/sec
Average segment structural overhead: 97.49 kbits/sec (19.13 %)
欲了解更多信息，请参阅流媒体验证工具的结果解释。
通过HTTPS安全提供文件密钥
您可以通过加密保护媒体。文件分割器和流分段都有加密选项，你可以设定定期更改加密密钥。有你设定谁与你分享的密钥。
密钥文件需要的初始化向量（IV），以解密加密的媒体解码。IV型可周期性地改变，就像密钥一样。目前对于尽量减少开销的建议是，每3-4小时更换密钥，每50 MB数据更换IV。
尽管被限制了密钥的访问，如果通过HTTP传输，密钥文件还是会被窃听者获得一份复制。一种解决方式是通过HTTPS安全地发送密钥。
在尝试通过HTTPS服务密钥文件前，你应该做一个测试，通过HTTP内部Web服务器提供密钥。这允许您添加HTTPS进来之前调试你的配置。一旦你有一个已知的工作系统，你就可以切换到HTTPS。
下面是通过HTTPS提供HTTP实时流密钥需要满足的三个条件：
- 你需要在你的HTTPS服务器上安装可信机构签署的SSL证书。
- 密钥文件的认证域必须相同作为第一播放列表文件的认证域。做到这一点最简单的方法是为从HTTPS服务器变种播放列表文件变种播放列表文件只需下载一次，所以这应该不会造成过大的负担。其他的播放列表文件可以使用HTTP提供服务。
- 您必须初始化自己的会话供用户进行身份验证，或者你必须在客户端存储凭据——HTTP实时流不提供进行身份验的用户对话。如果你正在编写自己的客户端应用程序，你可以存储凭据，基于Cookie桌和HTTP摘要，并提供在didReceiveAuthenticationChallenge回调的凭证（详情请参阅使用NSURLConnection和验证的挑战和TLS链验证）。您提供的凭据会被缓存，并通过媒体播放器重复使用。
重要：你必须拥有由认证机构签发的SSL证书以使用HTTPS服务器来提供HTTP实时流
如果您的HTTPS服务器没有被信任的机构签署的SSL证书，你仍然可以通过创建一个自签名的SSL证书管理局和服务器叶证书测试您的设置。将需要认证的证书附加到电子邮件，发送给你想作为一个直播客户端的设备，并点击邮件中的附件，使设备信任服务器。
一个例子记录在HTTP实时流中的MPEG-2流加密格式
常见问题
-
何种类型的编码器被支持？
协议规范不限制编码器选择。不过，目前苹果实施应开发含有H.264视频和AAC音频（HE-AAC或AAC-LC）的MPEG-2传输流编码器。与通过UDP传输流的广播软件兼容的编码器应该也与现在Apple提供分段器兼容。 -
支持的视频和音频详细格式？
尽管协议规范不限制视频和音频格式，目前Apple支持一下格式：- 视频
- H.264 Baseline Level 3.0, Baseline Level 3.1, Main Level 3.1, and High Profile Level 4.1.
- 音频
- HE-AAC or AAC-LC up to 48 kHz, stereo audio
- MP3 (MPEG-1 Audio Layer 3) 8 kHz to 48 kHz, stereo audio
- AC-3 (for Apple TV, in pass-through mode only)
- 视频
-
媒体文件应持续多长时间？
要考虑的主要因素是，短段导致索引文件更频繁的刷新，这可能会给客户不必要的网络开销。长段将延长广播和初始启动时间的固有延迟。每个媒体文件持续10秒似乎可以保持大多数广播内容的合理平衡。 -
在一个持续的会话期间，应该在索引文件上列出多少文件？
一般推荐数量为3，但是可用数量更大。
当选择最佳数量要考虑的很重要的一点是做播放/暂停和搜索操作时，在实时会话中提供的文件数量限制客户的行为。列表中的多个文件，时间越长，客户端越可以被暂停，而不会在广播中失去它的位置，进一步的回加入流时，以及更广泛的时间范围内，客户端可以寻求新的客户端开始广播。权衡是一个较长的索引文件会增加网络开销，在实时播放过程中，客户端都定期刷新索引文件，因此它确实增加了，即使索引文件通常很小。 -
何种数据比率被支持？
一个内容提供者选择一个流的数据率最大的被目标客户端平台和预期的网络拓扑影响。流协议本身不限制可使用的数据传输率。当前的实现的基于到iPhone的音频、视频流测试使用的数据比率低至64 Kbps和高达3 Mbps。仅音频流建议以64Kbps作为选择通过慢速蜂窝连接流传输。对于推荐的数据传输速率，请参阅准备传输至iOS设备的媒体
备注：如果数据比率溢出了可用带宽，在启动前会有更高延迟，并且可语段可能需要暂停以缓冲个多数据。如果广播使用了提供滑动窗口访问数据的索引文件，这种情况下客户端会被逐渐落下，并导致丢掉一个或多个段。在VOD模式下，不会有段被丢掉，但是不充足的带宽会导致慢启动和在数据缓冲时周期性的失速。
-
.ts文件是什么
.ts文件包含了一个MPEG-2传输流。这是一个封装的一系列编码媒体样本的文件格式——一般是音频与食品。文件格式支持多种压缩格式，包括MP3音频，AAC音频，H.264视频，等等。目前并非所有的压缩格式在苹果的HTTP实时流被支持。 有关当前支持的格式列表，请参阅媒体编码器。MPEG-2传输流是容器，并且不应该与MPEG-2压缩混淆。
-
.M3U8文件是什么
一个.M3U8文件是一个可扩展的播放列表文件的格式。这是一个包含UTF-8编码的文本的m3u播放列表。 m3u文件格式，是适用于承载的媒体文件的URL列表的事实上的标准播放列表格式。这是作为HTTP实时流索引文件的格式。详情请见：IETF Internet-Draft of the HTTP Live Streaming specification -
客户端软件如何确定合适切换流？
当前实现客户端实现是在播放时观察有效带宽。如果较高质量流可用并且带宽足以支持它，客户端会切换到更高的质量。如果一个低质量的流可用并且当前的带宽不足以支持当前流，客户端会切换到一个较低的质量。备注：对于备用流之间的无缝转换，流的音频部分应该在所有版本相同。
-
我可以在那里找到苹果的媒体流分段器？
媒体流分段器、文件流分段器和其他工具会经常更新，所以你应该在苹果开发者网站上下载最新版本的工具。参见下载工具 -
对于苹果的分段器和典型的含备用的HTTP流，推荐设置是什么？
参见准备传输至iOS设备的媒体
这些设置是当前建议。也有一定的要求。在ISO/ IEC13818的传输流定义必须包含H.264（MPEG-4，第10部分）视频和AAC或MPEG音频。目前的mediastreamsegmenter工具，仅支持MPEG-2传输流。如果使用AAC音频，它必须有ADTS头标。 H.264视频接入单元必须使用一个访问单元定界符的NAL，并且必须是独特的PES包。该分割器也有一些用户可配置的设置。您可以通过从终端应用程序中输入man mediastreamsegmenter获得的命令行参数及其含义列表。 媒体段的建议长度为10秒，如果未指定目标的持续时间则是默认的。
-
我如何指定何种解码器或H.264配置文件以播放我的流？
使用EXT-X-STREAM_INF标签的CODECS参数。当这个参数被表示是，他必须包含所有需要的解码器和设定以播放流。下列的数值目前可以被识别。类型 参数 AAC-LC "mp4a.40.2" HE-AAC "mp4a.40.5" MP3 "mp4a.40.34" H.264 Baseline Profile level 3.0 "avc1.42001e" or "avc1.66.30" Note: Use "avc1.66.30" for compatibility with iOS versions 3.0 to 3.1.2. H.264 Baseline Profile level 3.1 "avc1.42001f" H.264 Main Profile level 3.0 "avc1.4d001e" or "avc1.77.30" Note: Use "avc1.77.30" for compatibility with iOS versions 3.0 to 3.12. H.264 Main Profile level 3.1 "avc1.4d001f" H.264 Main Profile level 4.0 "avc1.4d0028" H.264 High Profile level 3.1 "avc1.64001f" H.264 High Profile level 4.0 "avc1.640028" H.264 High Profile level 4.1 "avc1.640029" 参数必须被包含在引用中。如果多个值被指定，一组引用会被使用以包含全部的值，并且这些值用逗号分开。
#EXTM3U #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000,RESOLUTION=720x480 mid_video_index.M3U8 #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=800000, RESOLUTION=1280x720 wifi_video_index.M3U8 #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=3000000, CODECS="avc1.4d001e,mp4a.40.5", RESOLUTION=1920x1080 h264main_heaac_index.M3U8 #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=64000, CODECS="mp4a.40.5" aacaudio_index.M3U8 -
我如何从视频音频输入创建仅音频流？
在使用分段器时加入-audio-only参数。 -
我如何想仅音频流加入一个静态图片？
在引用流时使用-meta-file参数活在使用文件分段器时使用-meta-type=picture以向每个段中加入图像。例如，下面的例子会将一个名为poster.jpg的图片插入到由track01.mp3生成的音频流的每个段中。
mediafilesegmenter -f /Dir/outputFile -a --meta-file=poster.jpg --meta-type=picture track01.mp3
请记住图像没十秒钟会被重新发送，所以请尽可能保证文件足够小。 -
我如何将一个仅音频流切换到视频音频流？
同时使用EXT-X-STREAM-INF的CODECS和BANDWIDTH参数。
BANDWIDTH参数指定了每个流所需的带宽。如果带宽足够音频使用，但不够最低质量的视频使用，客户端会写换到音频流。
如果OCDECS参数被包括，它必须列出播放流所需的所有编码。如果只有一种音频编码被指定，流会被标记为仅音频。目前不需要指定流是仅音频的，所以CODECS参数是可选的。
下面是一个例子，参数为快速链接速率为500Kbps，慢速链接速率为150Kbps，极慢连接速度为64Kbps。所有流都应该使用同样的64Kbps音频来保证不同流之间不会有显著差异。#EXTM3U #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000, RESOLUTION=1920x1080 mid_video_index.M3U8 #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=150000, RESOLUTION=720x480 3g_video_index.M3U8 #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=64000, CODECS="mp4a.40.5" aacaudio_index.M3U8 -
服务器的硬件要求或者推荐要求是什么？
硬件需求请参考问题1.
苹果流分段器可以在任何Intel平台的Mac上运行。我们推荐使用有两个网络接口的Mac，例如Mac Pro或XServer。一个接口用于从本地网络接收编码的流，另一个接口提供访问网络的带宽。 -
HTTP实时流支持DRM么？
不支持。但是媒体可以被加密，密钥访问可以在客户端向HTTPS服务器请求时通过认证限制访问。 -
何种客户端平台被支持
iPhone、iPad、iPod touch（需要iOS3.0或更高）、Apple TV（version2或更高）以及Mac OS X电脑。 -
协议规范可以在那里找到？
协议规范是一份IETF互联网草案，详见http://tools.ietf.org/html/draft-pantos-http-live-streaming -
客户端会缓存内容么？
索引文件包含指示客户端是否需要缓存内容。否则客户端会缓存数据以减少搜寻数据时的开销。 -
这是一个实时的配送系统么？
不。它具有对应于含有流段中的媒体文件的大小和持续时间的固有等待时间。至少一个区段必须完全下被载，才能在客户端查看，并且可能需要确保段之间的无缝转换。此外，在编码器和分割器必须从输入的文件创建;这个文件的持续时间是之前媒体可供下载的最小的延迟。与推荐设置典型的延迟是30秒左右。 -
等待时间是什么
对于推荐设置来说大约30秒。参考问题15. -
我需要一个硬件编码器么？
不需要。根据协议规范，使用软件编码器也是可行的。 -
使用RTP/RSTP有何种优点？
HTTP不太可能由路由器，NAT或防火墙的设置被禁止。没有端口需要被打开时默认情况下通常关闭。内容因此更容易得到通过对客户端的多个位置，无需特别设置。 HTTP也被更多的内容分发网络，它可以在较大的分销模式对成本的支持。一般情况下，更多的可用硬件和软件的工作原理未修改并打算与HTTP比RTP / RTSP。专长于使用自定义工具，如PHP HTTP内容交付也比较普遍。
此外，HTTP实时流是在Safari支持和iOS的媒体播放器框架。不支持RTSP流。 -
为什么我的流比特率比视频音频比特率总和稍高？
MPEG-2传输流可能包含更多数据。他们利用固定大小的数据包时，包的内容比缺省包大小较小时会被填充。编码器和多路复用器实现他们的效率在包装媒体数据到这些固定的数据包大小有所不同。填充量可以与帧速率，采样率，和分辨率而改变。 -
我如何减少数据超出并降低比特率？
使用更有效的编码以降低超支，或调整编码设置。 -
左右的媒体文件都需要是同一个MPEG-2传输流的一部分么？
不需要。你可以混合来自不同流的文件。通过EXT-X-DISCONTINUITY标签来区分。参考协议规格来获取更多细节。为了取得最佳效果，所有媒体文件应有同样的分辨率。 -
我可以在哪里找到关于设置HTTP视频/音频服务器的帮助？
您可以访问苹果开发者论坛
也可以查看Best Practices for Creating and Deploying HTTP Live Streaming Media for the iPhone and iPad
Copyright © 2020 Powered by MWeb, Theme used GitHub CSS.