前言

自己都是对直播这个模块很好奇，觉得是很深的，一直没有学习的机会，没有再项目中运用到，现在根据自己网上看到的文章

推流：指的是把采集阶段封包好的内容，传输到服务器的过程。

拉流：指服务器已有直播内容，用指定地址进行拉取的过程。

主流的推送协议

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/音视频学习笔记/