卡顿问题

在帧率达到10fps并且均匀播放是，就不太能看出来卡顿。

卡顿问题出现的可能性

1、帧率不够

两帧之间的间隔超过200ms，可能会出现卡顿

可能原因：机器性能不够，导致处理耗时太长。

解决办法：使用GPU做处理

2、编码出码率超过实际网络带宽

1）在RTC中比较常见，有时候网络突然变差，从网络预估出来的带宽很小，但实际播放的画面复杂，且需要的编码码率又比较高，容易出现发送码率大于实际带宽的问题。

当包被丢弃，后面参考它的帧都不能解码，直到IDR帧到来。

解决办法：

对发送码率做严格控制，防止它超过预估带宽

在RTC视频通话场景，最好选择CBR码控算法；

2）复杂帧编码后过大，或者I帧比较大

使用CBR的码控来编码可以使得一段时间内的编码输出码率尽量接近预估带宽，但有时候编码画面很大的帧或者需要编码IDR帧的时候，还是会使得变化后的一帧会比较大。如果一次将这帧打包 发送到网络，会加重网络负担，容易丢包，引起卡顿。

解决办法：

在编码打包之后，发送之前，加一个平滑发送的模块来平滑发送视频包。在webrtc中叫做PacedSender.

其主要的工作原理就是编码输出的码率打包后先放到缓冲区中，而不是直接发送。之后再按照预估带宽大小，对应的发送速度，将缓冲区中的数据发送到网络中。

一般PacedSender每隔5ms左右发送一次包，并且它会在内部记录上一个5ms发送周期发送完之后剩余可发送的大小。同时计算当前距离上一次发送包的时间差，乘上发送码率得到这段时间可以发送多少大小的数据。再加上上一次剩余可发送的大小得到本次可以发送大小。

3、网络本身有一定的丢包率

使用CBR好平滑发送，但有时候网络变化太快或者处于无线网络中，就有可能丢包。

丢包重传策略在jitter bufer实现。当接收端接收到视频RTP包后，会检查RTP序号

1、如果序号不连续，认为可能丢包了（也有可能UDP乱序）。Jitter Buffer将中间没有收到包的包序号加入到丢包列表中（UDP乱序去除）。

2、接收端每隔一定时间将丢包列表组装成RTCP协议中的NACK报文发给发送端。发送端会保持之前发送的历史数据中找到这个包重新发送给接收端。一来一往的时间差不多是一个RTT时间。

3、如果接收端等待一个RTT时间后还没有收到对应的RTP包，再次将该序号加入到重传请求中，如果连续多次没收到，那就不再将该包加入到NACK报文中了。

一般来说，策略使用后，卡顿一小会儿。如果重传没有收到包。那就要使用关键帧请求I帧请求。

视频花屏

1、帧不完整

帧不完整也有很大可能解码成功，但是得到的是花屏。

如何保证帧的完整性

• RTP打包的时候以Slice为单位打包，而不是以帧为单位打包。一帧可能有多个Slice，RTP包里，RTP头有一个标志M，便是一帧的结尾。Jitter Buffer中对帧进行完整性判断。先保证一个Slice是完整的。Slice_header中first_mb_in_slice字段，判断当前slice是不是第一个slice。
• 还有一种方式，使用时间戳相同的RTP包是同一帧。

  2、参考帧不完整，导致花屏

  连续参考帧，有一帧没有解码，就会出现花屏。SVC编码，不是连续参考帧

3、YUV格式问题

Y分量是对的 UV分量不对

4、stride问题

步距和视频的宽是两个概念