视屏卡顿的问题分析和解决
1.播放端远程播放是视频卡顿，有哪些可能的原因？如何分析和定位？
1.1 有点小卡顿，可能的原因和解决方法
1.1.1 网络传输有时候稳定性起伏较大。
1.1.1.1 定位手段：
网络的情况往往是比较复杂的，定位一个网络是否稳定还是比较难的。之前遇到的网络不稳定可能是因为：
1.1.1.1.1 wifi不稳定。
在同一wifi局域网内的两个设备相互ping包发现丢包十分严重。比较图1-1
图1-1
1.1.1.1.2 使用wifi，但是所在的地理位置开放的wifi很多。
wifi太多会相互影响而不稳定。可在周围wifi不多的时候看看测试效果。
1.1.1.1.3 使用4G或3G进行连接互联网，但是4G或者3G的信号时强时弱。
有时候用户使用的场景是移动的，比如人走到屏蔽手机信号的电梯里时，手机信用就会很弱了，这时候视频会卡顿甚至账号掉线。可换到信号稳定的地方看看测试效果
1.1.1.2 解决方法：
1.1.1.2.1 用户自己需要保证网络的稳定可靠
1.1.1.2.2 使用SDK在播放端的缓存机制。
缓存机制原理就是通过队列来按顺序保存接收到的帧，再使用定时器控制播放，这样就算网络有一些小抖动，采集端看到的视频也是流畅的。
实际在代码中的操作为：播放端在调用videoStart（实际名字请看具体SDK和平台的文档）这个API添加Delay选项（这个值越大，视频消抖动能力越强，但是采集和播放的时差会越大），如图1-2
图1-2
1.1.2 采集端videoStart的参数配置不正确
1.1.2.1定位手段：
1.1.2.1.1通过EventProc回调的videoStatus打印进行分析从而获取实时信息。帧率，码率，分辨率都是关键影响因素。
1.2.1.1.1 实时码率超过视频采集上行带宽。
如图1-3.可以看出码率是4018944bps，相当于4M的码流了，我们个人用的上行带宽一般是2M到3M多（网络上行带宽也有可能被其他设备占用），当视频采集一端的上行带宽不够时，视频就会出现卡顿了。
图1-3
1.2.1.1.2 码率在上行带宽支持范围内时，分辨率设置太大导致实时帧率太小。
从播放端的videoStatus看到的实时帧率长期都是一个比较小的数值，可能就是由于视频分辨率太大引起的。原理是：视频分辨率越大，每帧的数据量就越大，在码率一定时，能够上传的帧的数量就会减少。
1.1.2.2 解决方法：
1.1.2.2.1 videoStatus看到的码率超过实际上行带宽所能支持的范围时，降低采集端videoStart的码率参数到适当值。
1.1.2.2.2分辨率超过网络承受范围时，要降低分辨率。
将采集端videoStart的分辨率模式为一个更低的分辨率模式（如果实际分辨率不在原先SDK提供的分辨率数组里面，需调用VideoModeSize重定义分辨率）。
1.1.3 采集端编码性能差或播放端解码性能差。
1.1.3.1 问题定位：
1.1.3.1.1 如果采集端使用外部采集，增加在将视频帧输入到SDK前把视频采集的时间戳打印。
查看设备编码得到的视频帧传入SDK的频率。如果编码性能不稳定，那么视频也会卡顿。
1.1.3.1.2 查看采集端的视频编码器的CPU占比。CPU占比太高的话，性能也会不稳定。
如果采集端是在linux上，可通过top指令进行查看CPU占比。如图1-3
如果采集端是在windows上，可通过任务管理器查看CPU占比。如图1-4
1.1.3.1.3获取播放端的log日志,搜索打印中的关键字符串
在log中搜索关键字符串 CPGExtVideo::VideoOutDecode, Decode failed （视频解码失败）。多次出现这各字符串的原因可能为以下两点：
1.1.3.1.3.1 播放端的视频解码器性能差
播放端解码器无法解析所输入的帧，就会导致解码失败丢帧，从而导致播放端看到的视频卡顿。
1.1.3.1.3.2 播放端的网络不稳定，网络时延很大。
网络时延太大时，视频解码器会一下收到很多个帧，这种情况下，解码器会解析不了这么多帧的，从而出现解码器丢帧。
1.1.3.2 解决方法：
1.1.3.2.1 如果是设备本身的视频编码或解码性能差，可考虑更换硬件方案。如果换不了硬件方案，可适当降低视频的流畅度或清晰度（参考1.1.2.2）。
1.1.3.2.2 如果是网络问题，则需要保证网络质量。
1.2 非常卡顿
1.2.1 某一端或两端的网络不稳定
1.2.1.1 问题定位可参考1.1.1.1
1.2.1.2 问题解决
1.2.1.2.1 用户需保证网络的稳定可靠性。
1.2.2 采集端videoStart的参数配置不正确，请参考前面的1.1.2
1.2.3 采集端编码性能差或播放端解码性能差请参考前面的1.1.3
