HTML5怎样实现视频直播功能-
前言
前不久抽闲对当前比拼火的视频直播，做了下研究与摸索，理解其整体实现流程，以及探究挪移端HTML5直播可行性方案。
发明当前 WEB 上主流的视频直播方案有 HLS 和 RTMP，挪移 WEB 端当前以 HLS 为主（HLS存在推迟性题目，也可以借助 video.js 采纳RTMP），PC端则以 RTMP 为主实时性较好，接下来将环绕这两种视频流协定来展开H5直播主题分享。
一、视频流协定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-2 TS（Transport Stream）容器之中；分割：把编码好的 TS 文件等长切分成后缀为 ts 的小文件，并生成一个 .m3u8 的纯文本索引文件；阅读器运用的是 m3u8 文件。m3u8 跟音频列表格局 m3u 很像，可以简略的以为 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 要求 / 相应，所以顺应性非常不错，不会挨到防火墙影响。但它也有一个致命的弱点：推迟现象非常显明。要是每个 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 来实现。
打赏
