Daily Archives: 2023/08/25


WebRTC
针对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 […]

webrtc弱网自适应(自动升降速)要点