针对webrtc在弱网的码率自适应机制的学习。列举了几个影响因素。有时间的话，再来继续深入研究。 编码发送层优先级 发送端利用带宽估计算法估算上行带宽，然后根据策略进行码率分配（rtcsdk上层会指定每一层的码率），到了webrtc后，webrtc会在此带宽配置下，按顺序优先分配码率，先小流，再中流，最后大流，当大流（或中流）分配到的码率小于大流（或中流）的最小码率时就会停发大流（或中流）。比如： 估算出来的带宽是1 mbps，小流分配了256kbps，中流分配了512kbps，这个时候留给大流的只有256kbps，但是如果大流指定了最小带宽大小256kbps，则大流就会被停发。 DegradationPreference策略 a)DISABLED：禁用，不进行任何调整；b)MAINTAIN_FRAMERATE：保持帧率，降低分辨率（主流默认用这个策略）；c)MAINTAIN_RESOLUTION：保持分辨率，降低帧率（双流默认用这个策略）；d)BALANCED：平衡，降级时先尝试降低帧率，如果当前分辨率不适合再降低帧率，则降低分辨率，然后再尝试降低帧率，依次交替进行；升级时也是先尝试升高帧率，如果当前分辨率不适合升高帧率，则升高分辨率，依次交替进行。 编码耗时统计 方法如下：编码使用率=视频编码时间/采集间隔时间（对分子分母进行样本收集并做平滑处理）视频编码时间 = 本帧编码结束时间 – 本帧编码开始时间采集间隔时间 = 本帧编码开始时间 – 上帧编码开始时间 系统每5秒执行一次CheckForOveruse任务， 当编码使用率连续2次超过阈值上限，则判定为OverUse触发降级AdaptDown；反之当编码使用率低于阈值下限，则判定为UnderUse触发升级AdaptUp。为避免震荡，判定为UnderUse时会有迟滞处理。 不同运行环境的编码使用率上下限阈值默认设置如下（%）：硬编：200/150软编：85/42mac软编：单核20/10，双核40/20，其他核心数85/42。（目前没用到） QP统计 与CPU使用度检测类似，初始化过程发生在编码器重新创建的时候（流初始化，或者编码格式变化）。QualityScaler通过统计、计算编码后的每幅图像的量化参数(QP,Quantization Parameter，相当于图像的复杂度)，当一系列图像的平均QP超过阈值时会调整分辨率(H264的合法范围是24~37)，超过37要降分辨率，低于24要提高分辨率。QP检测的主体代码在quality_scaler.cc的QualityScaler类中，后者作为observer注册到VideoStreamEncoder中，VideoStreamEncoder内完成了相关流程的控制。 每帧编码图像的QP值会被加入样本集中，然后周期性调用CheckQpTask（默认每2秒，但前一次执行结果会影响下一次执行的周期）。 qp的变化通过回调进行反馈。在函数ReportQPHigh中会修改fast_rampup_ = false; 目的是分辨率一旦降低后，CheckQP调用的周期将变长，再提高分辨率的话，需要等很长时间。 经在不同终端上的测试，不同运行平台的QP值上下限阈值，当前版本的默认QP值设置如下：硬终端：22 ~ 45（插件中自己定义）Windows：24 ~ 37（已经改成24 ~ 42）Android：24 ~ 37（已经改成24 ~ 45）ios/mac：28 ~ 39（已经改成28 ~ 45）特殊环境下如果QP阈值默认设置不合适，可以通过WebRTC-Video-QualityScaling这个FieldTrial来设置修改，但一般情况下不建议修改。 降分辨率策略 交替乘 2/3 and 3/4以缩小分辨率到最接近目标分辨率，然后这个最接近的分辨率。Alternately scale down […]
