WebRTC开发之iOS15.4快速晃动，远端观看卡顿掉帧问题

Posted 2022-11-04 hbblzjy

前两周刚刚更新了ios15.4的系统，然后就发现了一个奇怪的问题，在iOS15.4的手机上安装音视频Demo，快速晃动时，远端看到的画面会卡顿，并且掉帧、帧率下降、不断变化，然而在其他系统手机上，却没有问题，所以是为什么？

1、难道是iOS15.4系统的采集修改，所以丢掉了部分帧？

2、难道是iOS15.4系统的硬编码修改，所以丢掉了部分帧？

3、难道是iOS15.4系统与WebRTC不匹配，所以WebRTC丢掉了部分帧？

根据这些猜想和疑问，在采集和编码处分别添加输出语句，测试多次发现：设置帧率15，快速晃动时，采集每秒输出15次，同一时间下编码每秒输出<15次，得出暂时的结论，出现丢帧、卡顿现象跟iOS15.4系统的采集、硬编码都没有关系，是采集的数据传到编码的时候，就有部分数据丢失了，那么只有可能是WebRTC遇到某种情况时，会进行丢帧处理，于是继续研究数据传输的代码。

果然，阅读数据传到编码之前的代码时，发现了一个丢帧处理的代码片段，代码如下：

Frame dropping is enabled iff frame dropping is not force-disabled, and rate controller is not trusted.（如果未强制禁用帧丢弃，且速率控制器不受信任，则启用帧丢弃。）

WebRTC默认情况下是不强制禁用帧丢弃，且速率控制器不受信任，所以会默认启用帧丢弃。然而force_disable_frame_dropper_（不强制禁用帧丢弃）这个值，WebRTC不具备更改此值的方法，需要自己添加，但是如果出现以下情况之一，则强制禁用帧拖放器：1、我们有分层的屏幕分享。或 2、“WebRTC FrameDropper”现场试验“已禁用”。

encoder_info_.has_trusted_rate_controller（速率控制器不受信任）这个值的设置，再研究研究。

既然知道是WebRTC主动进行帧丢弃处理，那么关于卡顿、丢帧的问题也就解决了，Happiness！

但是，是不是应该有这样一个疑问：为什么WebRTC要主动进行帧丢弃？什么条件下才会触发帧丢弃？正所谓：知其然而知其所以然。于是，继续分析触发帧丢失的条件。

首先看frame_dropper_.DropFrame()方法，

This function signals when to drop frames to the caller. It makes use of the drop_ratio_ to smooth out the drops over time.（此函数指示何时向调用者丢弃帧。它利用下降率来消除随时间的下降。）

此方法中主要是根据drop_ratio_.filtered()的值来进行处理的，所以进一步分析drop_ratio_.filtered()，其实这个就是下降率的过滤值，此值的变化，从而影响是否进行帧丢弃。而触发这个值的变化，是在上面提到的执行判断是否丢帧的地方之前，执行frame_dropper_.Leak(framerate_fps)

此方法，会根据目标码率和输入的帧率进行计算，然后再执行UpdateRatio()，更新下降率，从而更新drop_ratio_.filtered()值。通过输出和分析上面两个方法，发现target_bitrate_（目标码率）和accumulator_（叠加器）的变化会影响drop_ratio_.filtered()值的变化，从而影响是否丢帧的判断结果。继续分析这两个主要值的变化。

1、target_bitrate_（目标码率）此值的更改是根据网络质量估算，设置比较稳定的值

2、accumulator_（叠加器）此值的更改是有加有减

先执行void FrameDropper::Leak(uint32_t input_framerate)进行减法

再执行void FrameDropper::Fill(size_t framesize_bytes, bool delta_frame)进行加法 

通过上面的计算后，进行if (accumulator_ > accumulator_max_)的判断，然后执行drop_ratio_.Apply()方法，更改filtered_的值。

至此，影响丢帧的判断就算基本分析清楚了。Perfect！

如果还有什么疑问，请留言，或者自行分析源码，相信你会有不一样的感觉。转载请注明出处，整理不易，谢谢。