结合实战，浅析GB/T28181（八）——视频丢包（卡顿、花屏、绿屏）排查

1 问题现象

在视频专网（局域网）中，通过GB/T 28181视频平台接入大量的网络摄像机，比如上百、上千，甚至上万台。当系统同一时刻实况点播并发的视频路数较多时，常常会在客户端或电视墙监视器上，出现视频卡顿、花屏、绿屏等现象。

是视频平台软件媒体转发性能跟不上，支撑不起当前的系统压力；还是网络带宽出现瓶颈、负载过高引起丢包；抑或是服务器/客户机配置不够，媒体转发或解码时，机器资源（CPU占用率、内存等）即将耗尽？面对用户一脸的疑惑和这一个个问号，此情此景，该如何是好？

客户端播放花屏截图

客户端播放卡顿截图

客户端播放绿屏截图

电视墙播放紫色条纹幻影截图

如果您碰到了这些问题，或类似的问题，先别急。其实这些问题，大部分情况下，都是由于网络丢包引起的。可能您会问，我使用ping命令ping过摄像机，ping过NVR，ping过下级平台了，ping的时候，没有延迟，更没有超时，怎么可能会是网络丢包呢？

Ping命令，一定程度上可以帮我们来调查网络是否连通，是否有延迟，是否有超时，但是面对视频流大并发传输这种应用场景，ping命令从准确率上来说，是不够的。那么我们用什么工具来排查是否网络丢包呢？大名鼎鼎的Wireshark，此时便可以派上用场了。下面跟我一起看一下用Wireshark怎么来分析和定位网络是否存在丢包。

2 排查思路

复现问题，进行排查：比如在客户端播放问题摄像机视频；

1，先确保前端摄像机设置的视频参数是合适的，视频参数主要包括：编码格式、分辨率、码率。结合项目实践经验，以下是比较合理的参数设置，供参考

海康摄像机

大华摄像机

宇视摄像机

2，确认该摄像机，在平台是直连接入的，还是NVR或下级平台推上来的。如果是直连接入，在平台服务器上抓SIP信令包，用摄像机IP地址过滤；如果是NVR或下级平台推上来的，用NVR或下级平台IP地址过滤SIP信令抓包；

3，客户端点击播放问题摄像机；

4，在平台服务器上，用IP地址过滤，抓信令（SIP）包，获取接收视频流的媒体服务IP和端口号；

5，在媒体服务器上，选中媒体服务IP对应的网卡，用收流端口号过滤视频流包；

6，查看媒体流是否有丢包。如果有丢包，联系现场人员或下级平台厂家，排查网络；如果没丢包，则要转换排查方向了。

3 抓包分析

比如摄像机是下级平台推上来的，那么在平台服务器上，抓取与下级平台的SIP信令包。并用下级平台的IP地址进行过滤。如下图所示，抓取实况点播INVITE信令交互包，从其SDP中，可以获取平台媒体服务的收流IP地址和端口号，比如收流端口是37610。

接着在媒体服务器上，对收流IP地址对应的网卡进行抓包，用端口37610过滤（抓取的是下级平台发给本级平台媒体服务的视频流RTP包）。

接下来将UDP包解码为RTP包：

接下来对RTP进行流分析

由截图得知，在时长54.6秒的抓包中，共抓取6274个数据包，其中丢包2518个，乱序包724个，丢包率达到了40.13%，相当高了。这么高的丢包率，一般在客户端展现的视频就是花屏、绿屏。丢包率低一些的，展现为卡顿、拖影。一般丢包率高于1%时，客户端和电视墙上播放的视频质量，就会受到影响了。

4 丢包外的思考

使用Wireshark基本可以判断和确定网络是否存在丢包。可如果网络不存在丢包，那怎么办呢？那就要从以下几方面着手分析和排查咯：

1、媒体服务器的网卡带宽是否满载。怎么排查？比如媒体服务程序的收流IP和发流IP配置在同一块网卡上，该网卡为千兆网卡，即1Gbps。如果收流流量与发流流量峰值之和，已接近或超过1G，那么就要考虑给媒体服务器添加网卡分摊流量了；

2、单台媒体服务器最大转发视频路数能达到多少？如果视频并发路数已超过单台服务器的路数，那么就要考虑给媒体服务器扩容，添加媒体服务器；

3、客户机的硬件配置是否合适？比如在客户端进行多画面高清视频播放，16画面、25画面、甚至36画面等，这个场景播放非常耗费客户机的CPU、内存和显卡资源，如果配置跟不上，也会引起视频卡顿、花屏、绿屏；

4、客户端播放库的排查，播放库软解能力评估与测试。

※※如果您还有其它方面的补充或建议，欢迎留言进行交流和讨论。原创不易，感谢您的耐心阅读和支持！