目前移动端直播只支持 HLS，所以我们重点了解移动前端 HLS 的解决方案。
HTTP Live Streaming
HTTP Live Streaming（缩写是HLS）是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。是苹果公司 QuickTime X 和 iPhone 软件系统的一部分。
它的工作原理是把整个流分成一个个小的基于 HTTP 的文件来下载，每次只下载一些。
当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。
在开始一个流媒体会话时，客户端会下载一个包含元数据的 extended M3U (m3u8) playlist 文件，用于寻找可用的媒体流。
目前客户端方面的支持:
- iOS 从 3.0 开始成为标准功能。
- Adobe Flash Player 从 11.0 开始支持 HLS。
- Google 的 Android 自 Honeycomb（3.0）开始支持 HLS。
- VODOBOX HLS Player (Android,iOS, Adobe Flash Player)
- JWPlayer (Adobe Flash)
- Flowplayer (Adobe Flash,使用 hlsjs 版本不使用 Adobe Flash)
- Windows 10 的 EDGE 浏览器开始支持 HLS。
一个提供 HLS 的服务器需要做两件事:
- 编码：以 H.263 格式对图像进行编码，以 MP3 或者 HE-AAC 对声音进行编码，最终打包到 MPEG-2 TS（Transport Stream）容器之中；
- 分割：把编码好的 TS 文件等长切分成后缀为 ts 的小文件，并生成一个 .m3u8 的纯文本索引文件；
可以简单的认为 m3u8 就是包含多个 ts 文件的播放列表。
播放器按顺序逐个播放，全部放完再请求一下 m3u8 文件，获得包含最新 ts 文件的播放列表继续播，周而复始。
整个直播过程就是依靠一个不断更新的 m3u8 和一堆小的 ts 文件组成，m3u8 必须动态更新，ts 可以走 CDN。一个典型的 m3u8 文件格式如下：
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000
gear1/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=311111
gear2/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=484444
gear3/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=737777
gear4/prog_index.m3u8
HLS 可以穿过任何允许 HTTP 数据通过的防火墙或者代理服务器，它也很容易使用内容分发网络来传输媒体流。不过缺点也显而易见：非常明显的延迟。
HLS 是将直播流分成一段一段的小段视频去下载播放的，所以假设列表里面的包含 5 个 ts 文件，每个 ts 文件包含 5 秒的视频内容，那么整体的延迟就是 25 秒。
当你看到这些视频时，主播已经将视频录制好上传上去了，此时就产生了延迟。
缩短列表的长度和单个 ts 文件的大小可以降低延迟，极致来说可以缩减列表长度为 1，并且 ts 的时长为 1s，但是这样会造成请求次数增加，增大服务器压力，当网速慢时回造成更多的缓冲。
苹果官方推荐的 ts 时长时 10s，所以这样就会大概有 30s 的延迟，这里我们就需要在实际情况中寻找一个平衡点。
其实还有一种强大的技术 webRTC，最大的缺点就是移动端支持不太理想。
声音和视频的采集
此处前端考虑的地方不多，只作简单了解。
目前移动端直播只支持 HLS，所以我们重点了解移动前端 HLS 的解决方案。
HTTP Live Streaming
HTTP Live Streaming（缩写是HLS）是一个由苹果公司提出的基于
HTTP的流媒体网络传输协议。是苹果公司 QuickTime X 和 iPhone 软件系统的一部分。它的工作原理是把整个流分成一个个小的基于 HTTP 的文件来下载，每次只下载一些。
当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。
在开始一个流媒体会话时，客户端会下载一个包含元数据的 extended M3U (m3u8) playlist 文件，用于寻找可用的媒体流。
目前客户端方面的支持:
一个提供 HLS 的服务器需要做两件事:
可以简单的认为 m3u8 就是包含多个 ts 文件的播放列表。
播放器按顺序逐个播放，全部放完再请求一下 m3u8 文件，获得包含最新 ts 文件的播放列表继续播，周而复始。
整个直播过程就是依靠一个不断更新的 m3u8 和一堆小的 ts 文件组成，m3u8 必须动态更新，ts 可以走 CDN。一个典型的 m3u8 文件格式如下：
HLS 可以穿过任何允许 HTTP 数据通过的防火墙或者代理服务器，它也很容易使用内容分发网络来传输媒体流。不过缺点也显而易见：非常明显的延迟。
HLS 是将直播流分成一段一段的小段视频去下载播放的，所以假设列表里面的包含 5 个 ts 文件，每个 ts 文件包含 5 秒的视频内容，那么整体的延迟就是 25 秒。
当你看到这些视频时，主播已经将视频录制好上传上去了，此时就产生了延迟。
缩短列表的长度和单个 ts 文件的大小可以降低延迟，极致来说可以缩减列表长度为 1，并且 ts 的时长为 1s，但是这样会造成请求次数增加，增大服务器压力，当网速慢时回造成更多的缓冲。
苹果官方推荐的 ts 时长时 10s，所以这样就会大概有 30s 的延迟，这里我们就需要在实际情况中寻找一个平衡点。
其实还有一种强大的技术 webRTC，最大的缺点就是移动端支持不太理想。
声音和视频的采集
此处前端考虑的地方不多，只作简单了解。