何老师讲的很棒
都是基础的，很受用。
好视通”如何通过FEC、NACK 、带宽自适应等技术，对抗网络丢包，保证复杂的网络环境下的音视频流畅性
- 百万分之一
- 无线网络
- 有线网络拥塞
- 移动流量占比 80% 弱网非常普遍
- 抗丢包
- 牺牲带宽
- 进攻 牺牲带宽，降低码率，减少丢包
- 4个数据 xor得到5个数据，任意丢了可以回复
- K值越大，延迟越大
- 带宽利用率低，冗余无差别，接收端实际上用不上这么多数据
- 不能100%恢复，连续丢包很难恢复
- 丢包随机，不要求100%恢复
- K 和R 重要参数的选择
- 相同K ，R越大，抗丢包恢复能力越强。消耗带宽越多。
- 根据丢包率计算R，丢包率大，R就选大。
- 公式：
- R/ (K + 2 ) 要大于网络丢包率。
- 真实的网络丢包率
- arq 之后的丢包率
- arq + fec 后，也就是qos之后 的丢包率
Ｋ 影响连续丢包能力，
－ 必须连续收满Ｋ个包
- 冗余度最多100%，R是K最大是K，R要大于连续丢包数。
- K >= 2R ??
- K 不能与2R 相等：？
- 加一段自己的代码：
uint32_t sendTs;//FEC包发送时间，带宽估计可到
uint32_t firstSeq;//该分组N个源包中第一个源包序号，与N结合，就可以判断出哪些源包属于此分组
uint8_t K;//分组源包数量 K,服务端可配
uint8_t R;//分组补偿包数量 R，由丢包率计算
uint8_t seqR;//当前补偿包序号，取值范围N，N+1......N+K-1
##特别关注小马率的QOS
- 人为加丢包率，制造弱网
- 一定丢包率下，小马率不如大码率.
- 大妈率，收到一个包，却动重传或者FEC解码。
- 小马率，ARQ 时间也会变大。
- 所以要尽量使用小包，小包会缩短丢包判断时间。
- 包小，那么包间隔也会越小，也会缩短FEC时延。
- FEC必须收到K个包才能恢复，包小了，恢复也会快。
- 小马率，要控制分组的长度，也就是K的大小。
- 大妈率，分组K长一点好，对狂连续丢包能力强。
- 为了减少时延，把FEC的分组长度变小一点。
- 减少包的大小，相当于减少了包的时间间隔。这样，小马率下回又比较好的效果。
ARQ
- N ACK 主要是指这个 做ARQ
- arq的特点：
-
- 收到rtt影响较大，时延是rtt的倍数。
- rtt越长，时延越大。
- rtt 越大，恢复能力越差。
- arq 在接收端有个时间长度限制的，不能无线等。
- arq的带宽利用率高，可以做到100%恢复。
- 如果丢包率不是100% ，又足够的时间，是可以恢复的。
- 但是高rtt的话，恢复的时间越长。
- 适用于 rtt小的场景。
- arq 丢包重传。
- arq是先知道丢包了，重传。
- 但是网络包是乱序的，药有判断策略。
- 松一点还是紧一点。
- 1和4丢了，fec自己无法恢复，必须通过借助arq。
- 策略：
- n和n+m的包不连续，人为之间的包都丢失了。
- 或者人为这种情况是乱序，等到一定的序号跨度，才认为是丢包。
- 更粗暴，等到下一个分组的包时，人为上一个fec分组丢失了。
- 判断早，浪费带宽。
- 判断晚了，影响时延和恢复能力。
- 所以实际使用：
- 对乱序进行统计，网络统计。。。。
- arq的包，就是重传包，也可能丢失，需要再次发起重传请求。
- 这个时间是rtt的一次函数，系数是可以调整的，如果数据比较重要，这个值可以取小一点。
- fec和arq都有缺点，要结合使用。
- 大部分人想到是分层，但是比较别扭。
- fec在下层，如果fec无法恢复，包送给arq，那么fec的冗余就浪费了，因为可能需要1个包fec就可以，但是给了arq，那么arq就要重传两个包。
- 所以实现的时候 arq和fec做成一个协议。
- 公用协议头和结构。
- 1 只丢失一部分包，fec解码恢复就可以。
- 2 无法fec恢复，hi使用arq 重传
- 3 数据没收到，无法确认是否收到。要等，或者arq重传。
fec和arq的选择
- 并不是每时每刻都启用fec和arq
- 根据rtt 来选择。
- rtt 小于20毫秒，只使用arq
- 因为arq 的带宽利用比fec高。
- rtt很大，arq的恢复能力显著下降，引入时延是rtt的倍数，如重传一次，250毫秒延迟。
- arq就不能容忍，这个时候就用fec了。
- 20毫秒和250毫秒之间，就用混合模式，同时使用。
- rtt 越长，分组设置越长，冗余度越大。
- 码率越大，分组越长，康连续丢包越强。
- 音频还能用plc技术来。
防守 ，拥塞控制
带宽估计
- 带宽估计的理解，不是估计带宽，是网络拥塞时，发现并降低拥塞，拥塞接触就提升码率/提示音视频质量。
- 拥塞控制 是 gcc 。谷歌拥塞控制。
- gcc原理，拥塞发生又俩现象：
- 1 包排队，造成包的传输时间变大，
- 2 中间排队缓存溢出，出现丢包了，第二个就是出现了丢包。
- gcc 总体方案：
-
- 基于包时延
- 2 基于丢包
- -
- 丢包率2%- 10% 保持带宽不变。
- 20% 以上降低带宽？
- 这个清晰点：
2 基于包延迟的拥塞控制
- 延迟梯度
- 收到两个包的时间间隔，以及包发出的时间间隔，差值。
- 足够灵敏，网络丢包初期就能探测到。
- 对于音视频流畅很有价值。
- 左边，正常情况下，一个包的端到端的传输时间是固定的，正常情况下，计算的延迟梯度是0.
- 右边， 发生拥塞时，包在网络上排队，导致到达时间晚，这样到达就晚了，人为网络拥塞了。
- 但是网络存在抖动，要去抖动，用卡尔曼滤波或者gcc最新的滤波去抖动，得到延迟梯度。
- 梯度与r 值比较，延迟梯度在区间之外之内。
- 门限值是根据网络情况动态改变的。
- 避免卡顿。
- gama值动态计算。
根据负载/延迟梯度 与gama值对比，得到网络负载情况
- 根据网络负载情况调整带宽
-
- 上面是一个状态机。
- 做拥塞控制的体会：
- gcc有个webrtc的开源实现。
- 做好gcc并不是很容易，效果是多个环节缓缓相扣的，要调的比较好，要深刻理解理论基础。
- 有些业务在于流畅度/清晰度/
- 强大的评估系统，收集指标数据，根据数据来判断。
- 调参数就没办法继续调。
动态r值如何计算
- r值最主要参考网络丢包率
- 网络丢包率又多种，
我也觉得，他说的gcc的gama值是怎么计算的。
- gcc的gama值，也就是门限值怎么得到；。
- 滤波器，拿到当前的延迟梯度，拿到门限值，门限值与之前的比较，看差值。
- 根据差值，当前计算的延迟梯度值，比上一次的门限大还是小?
- 如果大，门限值加大，小，门限值减少。
康丢包测试公网
- 公网rtt大约是70 到80毫秒？
-音频 上下行 同时70%丢包。 - 视频是50%。
- 视频720 FHD 上下行50% 时延是300-400多毫秒。
- 接收端的重传控制是等待时间，上线是500毫秒，超过就人为是丢失了。
