debug&code的专栏

优化的目标是: 原生的策略是缓升快降, 改成平稳变化, 提高了AI阶段码率提升的速度, 同时降低MD阶段码率减少的速度.加大拥塞持续时间的判断，避免出现因硬件原因造成网络波动造成的误判断为拥塞。

pli fir

fec nack webrtc

fec nack webrtc

1. 计算fec 媒体分组大小(通过丢包率和单个视频帧的码率计算得到)(如fec媒体分组大小是2的话,表示fec模块 每缓冲两帧视频帧大小的rtp数据就开始进行fec编码

yuv数据的获取

现实生活中，大多数设备都位于NAT后。比如连着同一个基站的移动设备，同一个小区的宽带用户等。NAT的存在使得设备间不能直接进行点对点通信。有时候为了流量节省，以及安全等原因考虑，我们希望不同NAT后的设备也能进行点对点通信，不需要经过第三方的数据转发。为了进行设备间的点对点通信，我们需要使用相关技术检测设备间是否有点对点通信的可能性，以及如何进行点对点通信。这些相关技术就是NAT穿透(NAT traversal)。NAT穿透是为了解决使用了NAT后的私有网络中设备之间建立连接的问题。

某畅想，聊cc 聊fec，聊pacer，对方说到吧MD阶段的乘性系数从0.75改为了0.9，的确有可能会提高发送效率，但是也牺牲了公平，但是组长会认为是有效果的高级优化，至少理论上是。然后对方又让我聊fec，我说到了媒体分组大小的计算，生成的冗余包的计算等，结果对方说让我多学习核心技术，我当时在想，所谓的核心是啥，所谓的twcc的线性回归？某构，能聊一下，fec，nack，平滑rtt等，没聊CC，无奈二面聊业务时，有些不记得了，被判断为基础不好，没过遗憾。改变思维，注意方法，少写代码，多聊天。

终于把 海康摄像头对接到 Android 上面了哈。JitterBufferMs=13 看起来延迟不高。

GCC:在ack时钟的作用下:(1) 计算即时rtt/平滑rtt (2) 更新基于丢包的拥塞评估算法 (3) Alr (4) 估算当前播放端的吞吐量 (5) 更新基于延时趋势拥塞评估算法,aimd调整码率 ...

webrtc bbr

在webrtc启动阶段，第一个ack时钟的是由探测的策略来产生，这时GCC通过探测来进行码率评估,类型tcp的慢启动