基于TCP的0.8s超低延时、150kb/s超弱网络、低卡顿稳定直播框架
本文介绍了一个在直播质量上大幅超过各大平台的直播框架，在低延时方面甚至超过普通的webrtc+rtmp。在CPU效率和响应速度上也是屈指可数的。基于跨平台开发思想，目前只完成了iOS部分，后续完成所有之后考虑开源，在这之前欢迎测试。
Git地址：https://github.com/MinorUncle/GJLiveEngineDemo
直播质量指标
- 低延时：延迟是数据从信息源发送到目的地所需的时间，也是基于TCP直播不可避免的严重问题，不可能做到UDP的一样的低延时，但是最大程度的降低延时是一个重要指标
- 少卡顿：卡顿一般包括两种：1，视频源本身的卡顿，主播差网容易导致，主要由于推流端连续大量丢帧，时间戳不规则。2，视频缓冲导致的卡顿。（带追赶功能的播放器，追赶时长也是重要衡量指标）
- 首帧快：指第一次点击播放后，肉眼看到第一帧画面所等待的时间。首屏打开越快，说明用户体验越好
- 高质量：视频流畅，马赛克少，视频清晰，音视频同步精确。
- 弱网适应强：在带宽低和变化快的网络情况下，能保证主播和观众的互动。
目前达到的目标
- 对绝大多数延迟能控制在1sec之内（800ms）（正常网络观看香港电台直播、网宿cdn,都能维持在800ms（估计值）之内，500ms也不惊讶）。
- 正常网络平均每次缓冲间隔大约10min，每次缓冲时间几百ms之内。
- 主播端超低带宽（总共150kb/s，音频固定64kb/s）时，仍然能保持流畅与观众音频通话，视频根据画质平衡降低码率，但是保证视频在期望的最高丢帧率下均匀流畅播放，稳定之后延迟在10s左右。
- 在各个方面优化首帧渲染，难以描述指标，但是绝对优于IJK。
- 在设置最大允许丢帧率的情况下适当丢帧，提高在弱网下的视频质量。
- 主播在带宽编变化极快时能稳定的控制发送缓存和快速恢复码率。
目前市场现状比较
目前直播有多种。
- 纯UDP，webrtc正逐渐成为此部分的主流标准，优点在于延迟低，普遍在500ms以下，webrtc在连麦架构上又分为多种，此处不细分。webrtc缺点在于协议的兼容性不是很广泛，更重要的是在主流的sfu架构上，流量消耗大，在直播场景下，对于观众角色多个主播需要拉多路流。
- webrtc+rtmp(http-flv)，主流公司主播端采用webrtc连麦推流，观众端采用rtmp(http-flv)拉流，能有效降低直播成本，并且延迟在3s左右（与cdn配置和gop大小有关），在可接受范围内。
- rtmp(http-flv)，绝大部分非连麦直播采用此种方式，推流采用rtmp，拉流采用rtmp或者http-flv，延迟基本在5s左右（与cdn配置和gop大小有关）。
- hls，兼容性好，延迟极大，不做过多解释。
本方案主要是基于TCP的低延时、低码率解决方案，兼容各种tcp直播。包括webrtc+rtmp直播的转推部分、rtmp直播、hls直播。在rtmp推流+rtmp(http-flv)拉流状态下能达到1s以内，并且在150kbps的码率下也能正常流畅直播。延迟高于webrtc，低于市面的webrtc+rtmp框架，但是在音画质上高于webrtc，特别是弱网情况下比较明显（但是像普通tcp直播一样，弱网也同样存在延迟很高的问题）。
以下是与市面一些平台的对比，其中本方案最后维持在6fps帧率（可调整）流程播放，能体现绝对优势，欢迎评测。
GOP优化：
长GOP优点：
1， 同码率下画质更清晰。
2， 同时在ffmpeg、vlc等一些播放器上秒开效果更好。
长GOP缺点：
1，观众一开始就是高延迟的画面，而且对非直播播放器，高延迟是只要出现就是不可减少的。
2，编码失败时GOP恢复、精确的seek耗时耗能。
优化结果：基于ffmpeg的播放器对绝大多数格式的视频需要缓存40帧，所以建议gop大于40帧，一般直播建议4s，非直播甚至可以10s。
####B帧优化
增加B帧优点: 增加清晰度，降低GOP恢复、seek的消耗。
缺点： 1，增加延迟。2，安卓兼容性问题。
优化方案，讨论：
一个非连续B帧导致增加延迟相对比较少（当帧率15帧时，延迟大概增加66.6ms，相对tcp的延迟1000-3000比较小），肉眼感觉不出来，但是压缩比却能提高很多。
对于安卓兼容性问题，可能有部分不能解码B帧的机型，可以采用软解码。
所以建议能编码带B帧的视频，建议带大量非连续B帧，编码可以不强制要求，但是解码必须兼容B帧。（像香港电台的视频流带有大量的、而且是2个连续的B帧。）
动态码率：
在主播端网络差会导致所有观众无法优化的高延迟和低质量的视频。
动态码率的目的，在延迟、质量和流畅度之间做最优的平衡。
优化方案：
动态码率是保证户外直播、国外差网络直播质量的基石。在靠谱的网络预测模型上进行码率调整。
调整方案为：最优先保证音频质量，对音频采取不丢帧不降码率。
对视频首先设置最优码率和最低能接受的码率，当网络差时首先不丢帧降码率，当网络继续变差时保证均匀丢帧的情况下降码率（安卓无法丢帧则只能不丢帧，画质会更差）。
带宽（网络质量估计）估计：
带宽估计主要为动态码率做基石。带宽估计和动态码率的优化方向在于：降低发送Buffer的缓存，充分利用网络带宽，码率调整频率低，能快速应对各种网络变化。
优化方案，简述：
TCP的带宽估计只能依赖的数据不多，只能依赖历史网络记录，缓存情况等采用自己的一套方案预测带宽、评估网络波动情况、配置网络灵敏度。但是有个通用的优化点是可以根据期望码率适当减低socket缓存，以减少误差。
CDN优化：
CDN解析耗时，有些CDN为了避免播放中的卡顿，同时也优化ffplay的秒开速度，会缓存超过若干个GOP，但是在带有追赶的直播播放器中会一开始播放就产生追赶。
优化方案：
1，对于观众这个高频率拉流的情况，可以缓存CDN IP地址省去了CDN解析时间（同时必要时也要跟新IP，避免严重干扰CDN调度）。
2，根据是否要考虑ffplay、vlc等的秒开效果来配置CDN缓存，如果考虑则至少缓存40帧，否则只缓存当前帧。
JitterBuffer优化
JitterBuffer作用：为了缓解网络抖动带来的视频播放抖动，但是当网络只要出现过一个大的波动，或者服务器缓存比较多时，在没有追赶机制的播放器，本地缓存容易过度，且一般播放时间越长，延迟越大。但是减少本地缓存又会引起播放卡顿，所以降低延迟的情况下，又不增加卡顿是JitterBUffer的优化目标。
JitterBuffer原理：增加本地缓冲区，来缓冲延迟的变化，保证延迟最大的视频帧到来之前，本地缓冲区有足够多的数据以维持视频正常播放，但是又要保持足够少的缓冲以减少延迟。
我们可以通过以上图来理解，buffer1产生卡顿，buffer2和buffer3都没有卡顿，但是buffer3显然延迟更大，所以该时间段内buffer2是最优的jitterBuffer。
jitterBuffer要点：
1，找到最佳缓冲值
2，选择合适的缓冲更新时间
3，选择合适的追赶阈值和停止追赶阈值
4，选择合适的容错阈值（抖动线性滤波）
优化探索
提出想法：
JitterBufer能大概预测下一帧来的时间，当音频或者视频数据暂时没有了而需要缓冲时，我们是否可以判断下一帧如果可以在指定阈值内到达，则不缓冲，直接用上一旧值去呈现。
成果：
目前已经完成，对抖动小低延时的网络能在保持超低延时的情况下大幅减少卡顿，但是对差网络没有正作用，也没有负影响。
再提出想法：
人对音频信息的变化更加敏感，是否可以使音频严格播放，而适当放松视频播放条件，来大幅减少卡顿率。
成果：
目前已经完成，能降低整体的卡顿次数。
再进一步提出想法：
基于上一个想法的前提下，音频数据的优先到达更加能够减少卡顿和降低延迟，而在网络差的情况下视频数据的积累会阻碍音频数据的发送，降低播放效果。是否可以优先发送音频数据，保证音频的播放流畅，从而降低卡顿，而通过视频的JitterBuffer控制视频的缓存来避免视频的渲染延迟。
计划方案：
在发送端音频缓存和视频缓存分开存放，音频缓存数据为空时才考虑发送视频数据。在播放端基于视频数据做JitterBuffer。视频在播放时间内到达则正常显示，超过渲染精度到达，则丢帧。除非拉流端网络问题，否则基本不会产生缓冲卡顿，但是会增大视频丢帧。但是延迟还是差不多。
再进一步提出大胆想法：
基于上一个想法的前提下，音频能稳定到达，是否可以通过音频的JitterBuffer控制缓存，来降低延迟。
计划方案：
过程类似上一个问题的解决方案，只是缓存通过音频的JitterBuffer来控制。会减低延迟，特别是主播网络差的时候，但是也会导致视频的大幅丢帧。
连麦直播
如果需要连麦直播，或者追求更低的延迟，请见 https://blog.csdn.net/i1065517719/article/details/82842254
成果展示
以下测试均在同一个6s上测试，分别展示了一个推流（480*640）对应一个拉流、两个拉流、三个拉流，和香港电台的拉流状况
