网络卡顿分析思路整理.docxVIP

视频卡顿分析流程 目录  TOC \o 1-3 \h \z \u  HYPERLINK \l _Toc426883916 视频卡顿分析流程  PAGEREF _Toc426883916 \h 1  HYPERLINK \l _Toc426883917 第一步骤：明确IPC对外数据流的走向。  PAGEREF _Toc426883917 \h 1  HYPERLINK \l _Toc426883927 第二步骤：理清楚排查问题思路  PAGEREF _Toc426883927 \h 4  HYPERLINK \l _Toc426883935 第三步骤：抓包数据分析  PAGEREF _Toc426883935 \h 5  HYPERLINK \l _Toc426883975 附件：工具使用分析  PAGEREF _Toc426883975 \h 13  第一步骤：明确IPC对外数据流的走向。 这个部分是基础首先要明确IPC都有哪些对外的数据流向，出现卡顿到底是出在哪条数据流上。 这个图像是IPC对外数据流的框架图，如果看的不够明白。下面有个简单框架图。首先要搞清楚连接IPC都有哪些设备和平台，要明确卡顿是在哪条视频数据流上卡顿的。连接IPC的是公司NVR还是第3方的存储设备；连接的平台是公司平台还是第三方平台。如果是第3方平台，具体平台名称是什么。比如：国标平台，鸿信平台，上海贝尔，电信平台，中兴力维。不同连接方式取视频流的方式也是不一样的，对应端口和发送视频流的协议都不同的。梳理清楚便于快速找到对应接口人处理问题。 WEB端浏览视频图像走的是80端口，视频流采用的流媒体协议。 IPC跟第3方NVR对接，基本都是走的ONVIF协议。视频流采取也是通过流媒体协议。 IPC跟公司NVR或者EVS对接，则走的是大华私有协议（SDK）。 IPC跟第3方平台对接，则走的是IPC中一个独立的功能模块（接入功能模块）接入这块功能有专门的开发小组进行维护。 IPC跟公司自己的DSS,SMARTPSS平台对接，则走的也是大华私有协议（SDK）。 明确了上述流后，确认是哪条环节上视频流出现卡顿。把对应这条数据流上的网络拓扑信息图搞清楚。按照提供的网络拓扑图信息进行分级进行定位。排查到底是那级节点出现卡顿。调试卡顿现象时候一定要把网络拓扑搞清楚。搞清楚网络拓扑信息这个步骤，不要进行推诿，也不要找借口，区域要自己想尽一切办法把网络拓扑信息搞清楚。不然后续定位卡顿问题，研发拒绝协助和出差排查问题。 第二步骤：理清楚排查问题思路 IPC设备跟电脑直连都卡顿（排除网线和电脑问题）用VLC和WEB，SDK测试DEMO都验证过卡顿。那后续就不用排查其它问题，直接联系研发进行问题处理。 直连测试正常。则按照上面讲述的数据流向，把数据流梳理清楚，把网络拓扑图搞清楚。按照网络拓扑图逐级进行排查，看到底是那级网络点出现卡顿。 尝试降低编码参数，比如降低码流。如果降低码流就不卡顿，初步可以判定是整个网络带宽不足导致预览视频卡顿。 尝试如果修改WEB端预览视频模式（实时和流畅）调整到流畅模式就不卡顿，也可以初步判断是网络问题导致。 如果通过降低码流，调整预览视频流畅模式还是卡顿。则这个时候查看设备端资源占用情况。如果设备端CPU占用率特别高，那就可能是设备端性能不足导致发送视频流有问题，从而引起卡顿。设备端CPU过高有可能是开启功能过多，也有可能是编码性能不足。如果把设备配置恢复默认还是设备端占用CPU过高，那就联系研发进行问题排查。另外一种情况就有可能是有过多的IP登陆IPC，导致前端IPC资源紧张，从而引起视频卡顿。还有一种情况就是设置编码的FPS为25帧/秒，但实际上上来的码流只有20帧/秒. 这样也会导致视频流卡顿。 如果前端IPC一切正常（CPU资源很空闲,直连也不卡顿），平台端和NVR端还是卡顿。这个时候就要着手定位网络问题。 分析编码数据的I帧大小。使用StreamEye码流分析工具分析录像文件红色柱状表示I帧数据，对应旁边的数字就表示是对应的I帧数据大小。一般在200K以下。如果是因为I帧过大，一般都可以通过降低码流，或者调整WEB端预览模式来进行验证。 第三步骤：抓包数据分析 抓包分析有大量网络重传数据包 ?UDP方式取视频流卡顿，经过抓包分析有大量的丢包数据。统计丢包数据效率的方法如下： ? ? ? ? ? 案例总结： 兰州监狱NVR播放录像卡顿 定位为解码库问题，NVR端处理。 杭州--地铁4号线视频卡顿 定位原因：385光口设备的网络驱动导致网卡适应成10M网卡了。 江苏--南京地铁3号线 问题描述：HF3200 图像卡顿 原因分析：网络中存在大量的 ARP 包，导致设备对这些包一直在