直播推流端是整个直播内容的生产源头。我们熟知的推流工具有：PC 推流工具 OBS、手持设备和各个直播平台的手机推流 App、针对一些复杂场景有更专业的导播台硬件等等。虽然工具众多，但推流端的整个工作流程还是比较固定的：
摄像头、麦克风采集 → 视频编码、音频编码 → 音视频封装合流 → 推流
在推流端我们可以针对用户播放体验做的优化主要包含：推流断流优化和推流延时优化。
在直播推流端，我们最关注的就是是否断流，因为推流断流最终可能造成播放端的卡顿、报错等问题，对直播业务有很大的负面影响。其中与推流断流相关的指标有下面这些：
- 推流断流率，推流发生过断流的会话占比。
- 平均断流次数，平均一次推流会话发生断流的次数。
- 平均断流时长，平均一次断流时长。
此外，对某些业务场景来说，直播延时也是很重要的一个指标，除了在 CDN 服务端和播放端做一些优化外，推流端也可以做一些推流延时优化。
1、推流卡顿优化
造成直播推流卡顿的原因主要有设备、视频流、网络这三方面。
1.1、选择较高性能的推流设备
高清视频的编解码往往会给硬件带来更大的压力，由于编解码造成的卡顿尤为明显。对于推流端因为开播需要音视频编码、播放礼物动画、展示聊天消息等能力，这些组件叠加很容易使得 CPU、GPU 过载而导致手机发热和卡顿。
如果是这个原因，解决方法有以下几点：
- 升级硬件、软件设备，提高兼容性和容错率
- 尽量使用硬编硬解方案，充分利用 GPU 加速
- 降低视频帧率码率，选择流畅或者标清画质进行推流
- 切换到 PC OBS 推流
1.2、确保音频和视频时间戳同步
在直播中，当音视频时间戳不同时，会影响画面渲染，导致画面解析时出现问题，造成一卡一卡的现象，音视频时间戳非单调递增会导致播放器在解析画面时出现错乱的情况，前后画面衔接会出现不连续甚至花屏的现象。
在实际场景中，有些推流中断的情况是由于设备音视频权限被抢占或打断造成的。比如，在推流时，弹出一个视频播放把音频权限模式给改掉了，导致推流没有音频采集权限而中断。这种情况在复杂的业务场景里是有可能出现的。
对应这种情况，可以这样解决：
- 1）如果能感知和监控音视频权限的变化，可以在权限变化时，将权限设置回正确的模式。
- 2）音视频采集权限被抢占最终会影响采集到的数据，所以也可以监控音视频数据采集缓冲区来判断是否采集权限出了问题，从而尝试恢复权限。
1.3、防止推流帧率过低
根据人眼的视觉暂留原理，每秒的画面帧数必须达到一定的数值，人眼观看才是连续有效的，帧率（帧率即每秒的画面帧数）过低会导致用户视觉感受是卡顿的。
此外，如果视频的帧率设置过低，可能导致视频流的编码方式与服务器有不兼容的情况，这样在服务器转码直播流数据时可能出现了解析错误，也会导致直播放卡顿的问题。
1.4、断流重连
直播从推流端，到服务端，再到播放端，各节点一般都会有音视频流数据的缓冲。在推流端发生断流，在各级缓冲没有消耗完音视频数据之前，如果能恢复数据生产，还是有希望避免播放端出现断播或卡顿的。这样一来，实现推流断流重连还是很有必要的。
推理断流重连的实现说起来其实比较简单，就是断开原有的推流会话，然后重启会话来建连推流。但这里有两点需要注意：
- 1）是要完善推流会话各层的错误回调，这样才能即使感知到推流中断，从而做重连；
- 2）要和服务端协商好推流连接的生命周期时效，保证重启会话建立的连接还是推流到原来的直播间。
推流断流重连还可以做一个间隔重试策略，比如，间隔 1s 重试一次直至推流成功或外部停止推流，或者重试间隔时间线性递增直至推流成功或外部停止推流。
1.5、退后台保持推流
在实际应用场景中，很多主播都是使用手机进行推流，这时会有一个问题，如果主播受到其他打扰，比如来了电话或者查看微信，就会退出应用，这时候也会造成推流断流。对于这种情况，可以支持退后台继续推流，不过有几点需要注意：
- 1）退后台如果继续采集音频可能涉及到隐私问题。对于这个问题，可以退后台停止采集，但是保持推静音音频数据。当然，如果产品上可以退后台继续采集音频，就使用系统的能力持续采集就好了。
- 2）退后台无法继续采集视频，这时候如果不推视频数据，那么可能会引起 CDN 和播放器的不兼容的问题。因为有的 CDN 和播放器是需要检查视频数据，以及根据视频数据做一些功能和策略的。对于这个问题，可以推退后台前的最后一帧画面，并且适当降低帧率来降低推流的码率。
- 3）由于退后台时间较长后，App 的网络请求可能被系统中断，甚至 App 可能被杀死。对于这个问题，可以尝试一些后台保活的方案，比如 iOS 可以在退后台后播放静音音频来保活。
1.6、码率自适应
推流端在遇到网络较差，音视频码率发送不出去的时候也会造成播放端的卡顿或者报错，因此推流端也需要做码率自适应来适配网络。
推流端的码率自适应主要是通过计算单位时间内编码码率与发送码率来判断网络的实时情况，然后可以根据多次判定的结果进行码率调整。
下面是 RTMP 推流码率自适应的一种示例策略：
- 网络状况判断：每秒统计当前
编码码率与发送码率进行对比，统计连续 10 次的对比结果，定义：这 10 次统计中发送码率大于或等于编码码率的次数在[N, 10]区间，则判定网络优秀；在[M, N)区间，则判定网络一般；在[0, M)区间，则判定网络较差。 - 如果网络优秀：可在不超过设定的码率或帧率最大值的前提下，提高编码码率或帧率。这里需要注意，提升码率需要慢慢来，例如每次幅度增加 25kbps-50kbps 左右。
- 如果网络一般，则不进行操作。
- 如果网络较差：1）优先降低帧率，例如认为 FPS >= 12 的流畅度可接受，则可以先将编码前帧率逐渐降低到 12，同时调整实时码率匹配此时的帧率，这样可以保证清晰度不变。2）当帧率降低到最小容忍值后，网络依然较差，则可以继续降码率。这里的策略可以是将码率每次降低 100kbps 左右；或者调整码率为最近连续几次发送码率的平均值。这里需要注意，降低码率需要快速降。3）如果依然发送阻塞，最后可以进行丢帧操作。丢帧的策略可以优先丢非参考帧 B 帧，然后丢 P 帧、I 帧，最后丢 Audio 帧。
1.7、多模板策略
上面讲的推流码率自适应主要是推流端在已经开播后动态适配网络的码率策略。而通常在开播前，我们也可以根据需要对开播端进行网络探测，从而配置不同的推流模板以适配网络。这里的推流模板包含了推流的码率、帧率、分辨率、GOP 长度、编码方式等参数。
推流多模板策略包括以下几个步骤：
- 1）定义多个推流模板。一般来讲，首先要根据编码方式分为多个模板组，比如 H.264 编码的推流模板一组，H.265 编码的推流模板一组；然后，帧率、GOP 长度保持一样即可；最后，码率、分辨率根据情况配置。
- 2）探测机型支持的编码方式，选择对应的模板组。不同的机型支持的编码方式可能不同，比如对于支持 H.265 硬编的机型，可以优先使用 H.265 编码，这时候就选择 H.265 编码的模板组。
- 3）开播前进行网络探测。这个探测过程按照推流模板组中的码率，从高到低进行推流测试，如果当前码率可以流畅推出一定时长，则采用该模板。如果推流不流畅，则可以降级到较低码率的模板继续进行推流测试，直到找到合适的模板。
1.8、AI 动态码率计算
通过 AI 算法加持，对于推流进行数据识别，将识别后的结果进行打分，得出需要准确的码率大小，这样可以更精准的控制码率，从而提升用户体验。
2、推流延时优化
直播过程中整体延时通常指的是生产端到消费端的延时，也就是推流相机采集的每一帧到用户观看的每一帧时间差，通常我们可以用秒表来粗略估算，但代码中可以使用 SEI 配合 NTP 时间戳进行计算。
推流端延时则是从推流端到 CDN 服务端的延时。要对推流端的延时做优化主要是控制推流端的缓冲区策略，此外更重要的是选择合适的传输协议。
2.1、推流缓冲区控制
推流端的缓冲区比较典型的通常有两个：音视频数据采集模块和编码模块之间的缓冲区，编码模块和网络发送模块之间的缓冲区。
当这两个缓冲区中累积的数据比较多时，推流端的延时就会比较大，所以需要优化采集模块、编码模块、网络发送模块的性能和协调性，尽量降低缓冲区的数据累积。比如，当编码模块压力比较大时，可能导致采集模块和编码模块之间的缓冲区数据累积较多，这时候可以调整采集模块降低帧率来减轻编码模块的压力。
2.2、基于 TCP 协议的推流
我们对当前主流直播技术做了分析，在低延时直播技术出现前主要有 HLS 和 RTMP/HTTP-FLV 两个协议。
主流直播技术延时
- HLS：延时主要来自编码解码时产生延时、网络延时、CDN 分发延时。由于它是切片协议，延时分两大块，一个是服务端有切片缓冲延时，另一个是在播放端防抖缓冲会有延时。切片的大小和数量都会 HLS 影响延时大小，一般在 10s 以上。
- RTMP/HTTP-FLV：目前国内大部分厂家在用的 RTMP，它相对于 HLS 在服务端做了优化。RTMP 服务端不再进行切片，而是分别转发每一帧，CDN 分发延时非常小。RTMP 延时主要来自播放端防抖缓冲：为提升弱网环境下抖动时直播的流畅度，缓冲延时一般有 5-10s。
这两类协议都是基于 TCP，国内厂商基本上已经将 RTMP over TCP 的延时做到的极致，如果一个协议仍然基于 TCP 优化延时，效果上很难优于目前的 RTMP。
TCP 由于其自身的一些特性，并不适用于低延时直播场景，主要原因如下：
- 重传慢：TCP 的 ACK 确认机制，丢包后发送侧超时重传，超时时间一般 200ms，会造成接收侧帧抖动。
- 拥塞判断不准确：基于丢包的拥塞控制算法无法准确判断拥塞，丢包并不等于拥塞；也会造成发送链路 bufferbloat，链路 RTT 增大，延时增加。
- 灵活性差：这是最主要原因，TCP 拥塞控制算法在操作系统内核层实现，优化成本较高，移动端只有利用系统已有的优化。
2.3、基于 UDP 协议的推流
低延时直播技术
上图是基于 UDP 的两种方案对比，第一种是可靠 UDP 方向，比如 Quic；另一种是 RTC 方案，比如 WebRTC。
从五个维度对两种方案进行对比：
- 传输方式：Quic 是可靠传输；而 RTC 是半可靠传输，特定情境下可对音视频有损传输，可有效降低延时。
- 复杂度：Quic 的复杂度非常低，相当于将 TCP 接口换位 Quic 接口即可，RTC 方案的复杂度很高，涉及一整套的协议设计和 QOS 保障机制。
- 音视频友好性：Quic 不关心传输内容，对音视频数据透明传输。RTC 对音视频更友好，可针对音视频做定制化优化。
- 方案完备性：从方案完备性方面来讲，Quic 是针对传输层优化，而 WebRTC 可提供端对端优化方案。
- 理论延时：经实验室测试以及线上数据分析，WebRTC 方案的延时可以达到 1 秒以内。
综上，Quic 方案的最大优点是复杂度低，不过这个方案要想达到更低的延时，也需要引入更多的复杂度。从方案的先进性上看，选择 WebRTC 技术的低延时方案，RTC 技术和直播技术的融合，是未来音视频传输技术的一个趋势。
