mp4格式播放器 直播大火，H5直播技术你知道吗？H5直播方案分析讲解

2017年视频直播可谓是大火，各种视频直播平台陆续登场，H5直播也逐渐成熟，今天就来讲解H5视频直播可行性方案的分析。

目前 WEB 上主流的视频直播方案有 HLS 和 RTMP，移动 WEB 端目前以 HLS 为主（HLS存在延迟性问题，也可以借助video.js 采用RTMP），PC端则以 RTMP 为主实时性较好，接下来将围绕这两种视频流协议来展开H5直播方案讲解。mp4格式播放器

一、视频流协议HLS与RTMP

1. HTTP Live Streaming

HTTP Live Streaming（简称 HLS）是一个基于 HTTP 的视频流协议，由 Apple 公司实现，Mac OS 上的QuickTime、Safari 以及 iOS 上的 Safari 都能很好的支持 HLS，高版本 Android 也增加了对 HLS的支持。一些常见的客户端如：MPlayerX、VLC 也都支持 HLS 协议。

HLS 协议基于 HTTP，而一个提供 HLS 的服务器需要做两件事：

编码：以 H.263 格式对图像进行编码，以 MP3 或者 HE-AAC 对声音进行编码，最终打包到 MPEG-2TS（Transport Stream）容器之中；

分割：把编码好的 TS 文件等长切分成后缀为 ts 的小文件，并生成一个 .m3u8 的纯文本索引文件；

浏览器使用的是 m3u8 文件。m3u8 跟音频列表格式 m3u 很像，可以简单的认为 m3u8 就是包含多个 ts文件的播放列表。播放器按顺序逐个播放，全部放完再请求一下 m3u8 文件，获得包含最新 ts文件的播放列表继续播，周而复始。整个直播过程就是依靠一个不断更新的 m3u8 和一堆小的 ts 文件组成，m3u8 必须动态更新，ts可以走 CDN。一个典型的 m3u8 文件格式如下：

可以看到 HLS 协议本质还是一个个的 HTTP 请求 /响应，所以适应性很好，不会受到防火墙影响。但它也有一个致命的弱点：延迟现象非常明显。如果每个 ts 按照 5 秒来切分，一个 m3u8放 6 个 ts 索引，那么至少就会带来 30 秒的延迟。如果减少每个 ts 的长度，减少 m3u8中的索引数，延时确实会减少，但会带来更频繁的缓冲，对服务端的请求压力也会成倍增加。所以只能根据实际情况找到一个折中的点。

对于支持 HLS 的浏览器来说，直接这样写就能播放了：

注意：HLS 在 PC 端仅支持safari浏览器，类似chrome浏览器使用HTML5 video标签无法播放 m3u8格式，可直接采用网上一些比较成熟的方案，如：sewise-player、MediaElement、videojs-contrib-hls、jwplayer。

2. Real Time Messaging Protocol

Real Time Messaging Protocol（简称 RTMP）是 Macromedia 开发的一套视频直播协议，现在属于Adobe。这套方案需要搭建专门的 RTMP 流媒体服务如 Adobe Media Server，并且在浏览器中只能使用 Flash实现播放器。它的实时性非常好，延迟很小，但无法支持移动端 WEB 播放是它的硬伤。

虽然无法在iOS的H5页面播放，但是对于iOS原生应用是可以自己写解码去解析的, RTMP 延迟低、实时性较好。

浏览器端，HTML5 video标签无法播放 RTMP 协议的视频，可以通过 video.js 来实现。

3. 视频流协议HLS与RTMP对比

二、直播形式

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/bofangqi/article-67761-1.html