项目中直播模块开发小记，自己负责其中的web端直播播放以及即时通信。遂将直播相关的技术点以及开发过程中遇到的问题记录下来，进行积累。
本文主要讨论直播协议。直播业务主要分为三块，采集端推流、流媒体服务以及播放端。在项目中，采集端，我们使用开源的OBS；流媒体服务，公司是依托腾讯云的云直播服务；播放端，web端使用的是同样是腾讯云提供的播放器，客户端应该也是依托腾讯云提供的播放器SDK。
直播协议
直播协议即流媒体协议，主要由RTMP、RTSP、HLS、HTTP-FLV。这边我们将主要介绍常用的RTMP以及HLS。
RTMP
RTMP(Real Time Messaging Protocol)，实时消息传输协议；是最初由Macromedia为通过互联网在Flash播放器与一个服务器之间传输流媒体音频、视频和数据而开发的一个专有协议，后Macromedia被Adobe收购。
-
优势
-
延时小，实时性高
- 基于 TCP 长连接，不需要多次建连；
- 从采集推流端到流媒体服务器再到播放端是一条数据流，因此在服务器不会有落地文件；RTMP的延时在3s之内，对于实时性要求高的直播，RTMP协议是很好的选择。
-
编码兼容性高
-
基本上所有的编码器（摄像头之类）都支持RTMP输出；windows系统的PC端的浏览器节本上都支持flash。
- 支持加密
RTMPE和RTMPS为加密协议 -
劣势
-
播放端兼容性差
- 苹果系的播放端都是无法直接播放的，需要依赖第三放解码器，由此会带来发热、耗电等问题。
- 移动端浏览器很少支持flash，所以flv格式文件的播放收到了很大的限制。针对这个问题，B站在2016年开源了flv.js，一个实现了在HTML5 视频中播放FLV格式视频的Javascript库；其实现原理是将flv文件流转码复用成ISO BMFF（MP4 碎片）片段，然后通过Media Source Extensions将MP4片段喂进浏览器。MSE页有同样存在一定的浏览器兼容性问题，但是支持度还是可以。相信之后浏览器的迭代，对于MSE的支持会越来越好。
caniuse网站给出的MSE兼容统计
-
HLS
HLS(HTTP Live Streaming)，是苹果公司实现的基于 HTTP 的流媒体传输协议，可支持流媒体的直播和点播，主要应用在 iOS 系统，为 iOS 设备（如 iPhone、iPad）提供音视频直播和点播方案。
-
优势
-
性能高
-
穿墙
-
互联网不可能不开放HTTP协议，否则就不叫互联网。所以任何端口封掉，也不会导致HTTP流看不了。（不过RTMP也能穿墙，用RTMPT协议）。
+ ##### 兼容性
+ 苹果开发的协议，所以在PC或者移动端的safari浏览器中，肯定是绝对支持；
+ 其他浏览器中支持也并不好。从下图中可以看出，时长占额较大的两大浏览器厂商Chrome和FireFox对苹果出的协议并不买账。所以强大的MSE又出场了，现在有开源的hls.js对m3u8格式的视频进行转码在pc端播放。
-
劣势
-
延时较大
HLS 的基本原理就是当采集推流端将视频流推送到流媒体服务器时，服务器将收到的流信息每缓存一段时间就封包成一个新的 ts 文件，同时服务器会建立一个 m3u8 的索引文件来维护最新几个 ts 片段的索引。当播放端获取直播时，它是从 m3u8 索引文件获取最新的 ts 视频文件片段来播放，从而保证用户在任何时候连接进来时都会看到较新的内容，实现近似直播的体验。相对于常见的流媒体直播协议，例如 RTMP 协议、RTSP 协议等，HLS 最大的不同在于直播客户端获取到的并不是一个完整的数据流，而是连续的、短时长的媒体文件，客户端不断的下载并播放这些小文件。这种方式的理论最小延时为一个 ts 文件的时长，一般情况为 2-3 个 ts 文件的时长。HLS 的分段策略，基本上推荐是 10 秒一个分片。 -
直播协议对比
总结
综上看出，rtmp和hls这两种主流的直播协议，当前是各有利弊；所以想要在各种场景下实现比较好的直播效果，就需要具体问题具体分析。
比如在PC，我们可以可以使用rtmp协议，由于当前浏览器对flash仍然后较好支持，PC端就可以充分发挥rtmp延时小，实时性高的优势；
而在移动端，hls协议的兼容性要更胜一筹，我们便可以使用该协议；
同时，我们还可以使用基于MSE对各种视频文件进行处理，得到兼容性更好的视频格式；
当然，使用第三方较为健壮的播放器也是个不错的选择；对于直播播放的讨论，会在该系列另一篇文章中进行讨论。
参考
1、直播协议的选择：RTMP vs. HLS
2、关于直播视频格式和浏览器兼容性历史的来龙去脉
3、理解RTMP、HttpFlv和HLS的正确姿势
4、RTMP HLS HTTP 直播协议一次看个够
