前言
自己都是对直播这个模块很好奇，觉得是很深的，一直没有学习的机会，没有再项目中运用到，现在根据自己网上看到的文章
推流：指的是把采集阶段封包好的内容，传输到服务器的过程。
拉流：指服务器已有直播内容，用指定地址进行拉取的过程。
主流的推送协议
RTMP：视频必须是H264编码，音频必须是AAC或MP3编码，且多以flv格式封包。
优点：对CDN支持良好，实现难度较低
缺点：不支持浏览器
HLS：基于HTTP的流媒体实时传输协议。原理是将整个流分为多个小的文件来下载，每次只下载若干个。服务器端会将数据生成新的小文件，客户端只要不停的按顺序获取到的文件，从而达到直播的效果。HLS是以点播的技术实现了直播的体验。
传输内容包括两部分：一是M3U8描述文件，二是TS媒体文件。
优点：不用考虑防火墙或者代理的问题，而且分段文件的时长很短。
缺点：延迟一般会高于普通的流媒体直播协议。
WebRTC：WebRTC是一个支持浏览器进行实时语音、视频对话的开源协议。本人只做移动端的，不做深入了解。有兴趣的同学自信百度
RTMP和HLS对比
RTMP：延迟低，基于TCP的长链接，数据处理及时，使用场景：即时互动。
HLS ：延迟高，短链接，原理是集合了一段时间的视频数据，切割ts片，逐个下载播放。优点是跨平台。
编码和解码
编码：压缩无用信息和不重要的信息的“压缩处理”，这就叫“编码”。
解码：还原为原始的信号（比如视频中某个点的颜色等），这就是“解码”
软编解码：使用CPU进行编解码，大多使用FFmpeg来编码和解压音视频数据；
硬编解码：主要使用非CPU进行编解码，如GPU等。在使用中，大多直接调用系统API进行音视频编解码处理。使用VideoToolbox中的VTCompressionSessionRef实现
FLV
flv是一种简单的视频合成格式。它支持指定的音视频格式，如：h263，h264，VP6 及 AAC，MP3，Nellymoser等。
flv刚好支持 h264 和 aac。
rtmp协议所传输的视频流，就要求是flv格式。
视频数据采集原理(推流)
1、音视频的采集
2、对视频进行 H264 编码，对音频进行 AAC 编码
3、对编码后的音、视频数据进行组装封包
4、建立 RTMP 连接并上推到服务端
视频播放原理(拉流)
解封装的作用，就是将输入的封装格式的数据，分离成为音频流压缩编码数据和视频流压缩编码数据
解码的作用，就是将视频/音频压缩编码数据，解码成为非压缩的视频/音频原始数据。
播放卡顿
造成卡顿的原因有几种情况
推流端网络抖动导致数据无法发送到服务器，造成播放端卡顿;
播放端网络抖动导致数据累积在服务器上拉不下来，造成播放卡顿。
弹幕优化
1.弹幕阴影通过NSAttributeString（富文本）的NSStrokeColorAttributeName属性设置文字的轮廓颜色替换文字阴影。
2.用CALayer替代UIView展示。
3.将内容合成一张图片展现
优化切换前后台带来的累积延时
第一种方案是播放器采用视频同步音频的策略，然后退到后台时保持音频继续播放（在 iOS 平台需要开启 App 的 Background Audio 能力来配合）。这样可以保持音频一直播放不产生延时，而当回到前台时，视频同步音频直接切换到最新时间戳即可。
第二种方案是回到前台时重新刷新直播，重连直播流，这样即可消灭累积延时。但是这种方案的问题是重连直播流的过程需要一定的时间，这样回到前台时会有卡顿，或者出现黑屏，尤其是当你的首屏加载优化不够时，这个卡顿或黑屏时间会较长。所以这种方案在你的首屏加载优化的比较好的情况下可以采用。此外，你可以退到后台时截取视频当前帧贴图到直播间上，从而当切回前台时，防止黑屏，优化体验，实践效果还是不错的。
参考
https://www.foolishtalk.org/2019/03/05/音视频学习笔记/