最近在部署公司的mas产品，遇到了好些坑，开帖记录一下。
1.主流直播方式介绍
目前pc端主要使用rtmp，移动端使用HLS直播。
- rtmp是adobe开发的协议，一般使用adobe media server 可以方便的搭建起来；随着开源时代的到来，有大神开发了nginx的rtmp插件，也可以直接使用nginx实现rtmp ，参见 基于nginx的rtmp的服务器
- HLS (HTTP Live Streaming) 直播 是有苹果提出的一个基于http的协议。其原理是把整个流切分成一个个的小视频文件，然后通过一个m3u8的文件列表来管理这些视频文件
- rtmp协议的默认端口是1935，即如果看到一个链接为 rtmp://www.xxx.com 其实等价于 rtmp://www.xxx.com:1935，而HLS由于使用了http，故默认端口是80
- rtmp方式的最大的优点在于低延时，经过测试延时普遍在1-3秒，可以说很实时了；缺点在于它是adobe开发的（囧），rtmp的播放严重依赖flash，而由于flash本身的安全特性和苹果爸爸的去flash化，导致目前移动端基本上是没有flash的，因此移动端(特指移动端浏览器和微信qq等常用app的自带浏览器)是无法使用rtmp的
- HLS完美适应H5的要求，是移动端浏览器天生的直播方案，唯一的缺点是延时大。
HTTP Live Streaming 并不是一个真正实时的流媒体系统，这是因为对应于媒体分段的大小和持续时间有一定潜在的时间延时。在客户端，至少在一个分段媒体文件被完全下载后才能够开始播放，而通常要求下载完两个媒体文件之后才开始播放以保证不同分段音视频之间的无缝连接。
此外，在客户端开始下载之前，必须等待服务器端的编码器和流分割器至少生成一个TS文件，这也会带来潜在的时延。
服务器软件将接收到的流每缓存一定时间后包装为一个新的TS文件，然后更新m3u8文件。m3u8文件中只保留最新的几个片段的索引，以保证观众任何时候连接进来都会看到较新的内容，实现近似直播的效果。
这种方式的理论最小延时为一个ts文件的时长，一般为2-3个ts文件的时长。
所以，hls的延时主要由以下三个部分组成：
a. 服务器端的编码器和流分割器生成TS文件的时间
b. 客户端下载TS文件的时间，而通常要求下载完两个TS媒体文件
c. 客户端解码并播放时间
这三个方面里面，前两个方面我们是可以控制调节的，对于第三个方面只能取决于客户端的性能。
2. 延时优化方向
a. 减少每段ts文件的大小——HLS官方推荐每段ts是10s，我们可以将之调小
b. 减小播放列表长度和最大ts循环数
参考的ffmpeg转码参数为：
/home/trs/trsmas/linux32/ffmpeg-2.0.1/bin/ffmpeg -report -re -y -i rtmp://120.220.230.130/masvod/nb_tv -c:v copy -bsf:v h264_mp4toannexb -c:a libfaac -hls_time 1 -hls_list_size 3 -hls_wrap 3 -start_number 1 /storage/masdata/HLSLive/22/nb_tv.m3u8
备注：我发现虽然设置了hls_time 1 start_number 1 ，但实际上生成的ts文件最短还是8s，ts文件起始编号还是从0开始，不太清楚是我使用的ffmpeg版本问题还是ffmpeg内置有ts文件最短时间，需要后面再验证
按照我这个参数调整下来，直播延时在23s的样子，一个ts文件8s，也就是延时是3个ts，勉强够用了
很多文档上都说，如果单个ts文件的时间变短会增加服务器性能消耗，但我没有感觉到，因为理论上ts文件越小，分片越少，延时就越小，但是我调的很小了也没有把延时降到10s以内，所以应该还有我未曾了解到的知识点
3. 直播中一些常见问题的定位
这里主要参考了 如何在直播中解决黑屏、花屏、闪屏问题 | 直播疑难杂症排查
4. ffmpeg 关于hls方面的指令说明
-hls_time n: 设置每片的长度，默认值为2。单位为秒
-hls_list_size n:设置播放列表保存的最多条目，设置为0会保存有所片信息，默认值为5
-hls_wrap n:设置多少片之后开始覆盖，如果设置为0则不会覆盖，默认值为0.这个选项能够避免在磁盘上存储过多的片，而且能够限制写入磁盘的最多的片的数量
-hls_start_number n:设置播放列表中sequence number的值为number，默认值为0
tips：m3u8文件在移动端浏览器可以直接打开(因为他们都支持h5)，在pc端目前只有edge浏览器可以直接打开，其他就需要播放器支持，如vlc、kmplayer等
