A frame in FIG.
Second, the frame rate regulation algorithm
according to the figure, the transmission frame rate adjustment algorithm has two ends:
1, video capture frame rate and encoding algorithm between FrameDropper input frame rate.
2, MediaOptimization algorithm between the encoder input and the output of the encoder.
Three, WebRTC frame rate
as FIG frame, from left to right WebRTC frame rate, the frame rate is held down state. Acquisition frame rate of the camera is to send the frame rate limit side.
1, camera capture frame rate
video capture card frame rate capability set, can be viewed potplay tool. Open -> Device Setup -> Camera
The camera can capture frame rate and camera models, video resolution related. He can provide the frame rate, video frame rate determines the maximum value of the sender.
2, an encoder input frame
theoretical encoder input frame rate of video capture frame rate or less. + Encoder encodes video capture frame rate performance determines the input frame rate of the encoder.
If the acquisition frame rate of the camera is 640 * 480 30fps, coding performance if the encoder 480 is 640 * 60fps, then the encoder input frame rate is 640 * 480 30fps.
If the relatively poor performance of the encoder, the coding performance is 25fps 640 * 480, then the encoder input frame rate is 640 * 480 25fps.
To achieve this minimum frame rate selection algorithm is FrameDropper funnel algorithm. Probably algorithm principle is that the timing of the funnel imported video capture frame rate to the queue inside the funnel, when the encoder performance schedule over, the algorithm to find data, the latest one will funnel to the video encoder.
See detailed implementation: VideoStreamEncoder :: EncodeTask-> Run-> OnIncomingFrame
3、编码器输出帧率
输入到编码器的视频帧，不一定全部被编码。如前面Send Side BWE介绍，当网络出现延时或者丢包的情况下，码率会持续下调。但是帧率不变的情况下，码率持续下调必然会导致视频质量快速下降。MediaOptimization大概思路就是通过降帧率的方法，降低码率。这样单帧的视频质量不会下降的特别明显。
详细实现参见：VideoSender->VideoSender::AddVideoFrame->_mediaOpt.DropFrame()
另外VP8、VP9、openH264都有一个EnableFrameSkip选项，开启该功能后，当视频编码输出的码率无法压缩到指定的目标码率，会通过掉帧的方式调节。导致实际输入编码器的帧数大于等于输出编码器的帧数。
4、网络接收帧率
同一帧视频的不同RTP的报文时间戳是相同的，一帧视频结束的最后一包的RTP报文头的MARK位为1。所以在网络测，判断一帧视频是否接收完全，同一个时间戳的报文的序列号是否连续，改时间戳的RTP报文是否收到MARK为1的包。
由于网络丢包延时等影响，网络接收到的数据帧若不完全，是不需要传递给解码器的，否则解码器也会解出花屏的数据。或者网络接收模块没有判断出数据有缺失，但是解码器判断异常，出现无法正常解码的情况。这样就会出现网络接收帧率大于等于解码器输出帧率的现象。
5、解码器输出帧率
如第四小节描述，这里仅统计完整正确能解码出视频帧的帧率。
6、视频渲染帧率
这是最终将第一小节的视频采集卡视频显示给用户的界面。可能出现个别终端的渲染器性能比较差，解码出来的全部数据不一定能及时渲染出来。目前webrtc在这里没有增加特殊处理，要是渲染不及时就会累积，出现视频延时的现象。
四、总结
可以看出webrtc只有在编码前的MediaOptimization算法里面主动丢帧降帧率。其余的地方是由于网络丢包延时、编码性能、渲染性能导致被丢帧。
五、参考
https://blog.csdn.net/chinabinlang/article/details/79654852
http://www.enkichen.com/2017/07/29/webrtc-drop-frame/