实况卡顿、黑屏常见问题定位方法

分类一、黑屏二、第

对接黑屏三、卡顿类实况黑屏的过程，实况黑屏是在局点使用时经常容易碰到的。这样的问题要么很容易定位，要么很难定位，我大致讲解下然后通过这三个步骤来排除问题。实况 成功的三个关键步骤：1、需要有

码流2、需要 成功3、显卡支持显示实况黑屏---需要有码流。这里有个知识需要大家了解下，wirsharke能抓到包，不代表客户端可以这类问题碰到比较多的就是PC设置了收到报文，因为wireshark直接在网卡镜像抓包，它的报文不会被windows系统给过滤，而 客户端使用的是windows系统函数，受

限制。所以wireshark能抓到报文，并不代表客户端可以收到报文。这里有几个方法可以确认是否收到报文：1）、通过windows的任务管理器2）、通过WEB客户端，查看码流大小这几步可以确认是否客户端是否收到报文。解决办法：1、检测本地PC是否打开了2、根据客户端SDP中的ACK报文，判断web客户端的收流端口与报文中流的目的端口是否一致。实况黑屏--需要 成功这个是实况的关键，大部分问题都出现在这个过程中。所以这个模块我会按几个方面描述。首先需要了解

支持的

流类型和对应的decodetag：1、 设备，使用的是

udp+ts，tcp+ts，

一般采用IMOS对接协议2、 设备，使用的是rtp+ts，tcp+rtp+ts，

一般采用 电力对接，db33对接3、 设备，使用的是rtp+ps，tcp+rtp+ps，一般采用国标对接4、 设备，使用的是rfc3984，tcp+rfc3984，采用onvif协议h3c-v3h3c-v3@20guobiao或h3c-v3@22sony，samsung，axis，onvif1.0onvif2.0，onvif2.1，流，采用IMOS对接协议。panasonic5、DA推送设备，使用的是RTP+第6、国标平台对接，使用的是RTP+ps流7，db33平台对接，使用的是rtp+第

私

流很多，见附件1guobiao很多，见附件2如何从报文和日志中查找对应的decodetag1、可以从报文中查看。客户端的任何实况都有sip交互的过程，在sip的ack中携带了decodetag，如图2、通过客户端的日志。客户端的日志保存在安装环境下的log

下，名字为sdk_client00.log,

搜索“set

channelDecoderTag”[IMOS_XP_SetDecoderTag]

[PortID:

0]

set

channel

DecoderTag

h3c-v3@22实况黑屏--需要 成功流不匹配的如何区分ts，ps，rtp+ts？大部分问题只要知道decodetag就差不多了，但是和第 公司对接，可能会出现携带的decodetag和情况。那么如何快速的区分呢？我主要讲ts，ps和rtp+ts流的区分，其他码流很难区分，所以不描述了。Ts流的特点是报文跟在UDP协议层之后的第一个字节是0x47，如下实况黑屏--需要 成功PS流：ps流一般都承载在rtp上，所以一般udp头之后会加一个12字节的rtp头，在跟ps数据。

Rtp头，一般头字节为0x80，或0x90，Ps每帧的头一般为00

01

BA（小技巧，一般rtp头的mark标志用来表示一帧的结束，所以在mark标志后的一个报文一般为一帧的头）如图实况黑屏--需要 成功RTP+TS，udp头之后+12字节的rtp头+ts流，

Rtp头一般为0x80，或0x90Ts头一般为0x47.实况黑屏--需要 成功理解了报文的构成后， 来说下报文的报文：对于ts报文，只要剥离掉udp头直接存为文件，vlc是可以正常 的。方法一般如下：要剥离udp头，在wireshark中使用如下方法，保存为xx.ts即可实况黑屏--需要 成功PS流的剥离：由于ps一般携带rtp头，所以需要先将报文转换为rtp，然后保存payload为

.ps实况黑屏--需要 成功理解以上后，接下来如何使用工具来定位问题。在实际定位中，其实并不需要了 流的细节，只需要知道decodetag即可。工具包含两个，1、XP_PLAYER_DEMO

器.exe2、Packe

d.exe

模拟发包工具该工具位于

/产品资料文档/平台资料/ 手册/ 工具/发包工具/器.exe放置在对应版本的安装路径下步骤：1、首先将XP_PLAYER_DEMO2、过滤码流报文。保存的码流格式必须为tcpdump格式，如下3、打开XP_PLAYER_DEMO 器.exe实况黑屏--需要 成功实况黑屏--需要 成功其中ip地址为XP_PLAYER_DEMO

器的本地ip和端口发送次数：指这个报文发送多少次？0表示一直循环发送，1表示只发1次发送间隔：指所有报文发送结束后，需要间隔多久在循环发送。：发包器有一个缺陷：不能重复打开同一个报文文件，如果需要发送同一个报文到多个地址，那么需要将报文文件

一份。发包器的报文间隔和实际抓的报文是一致的；对于使用的是tcp协议，则需要选择tcp发送，但是XP_PLAYER_DEMO

器还是选择udp。发包器只是将tcp报文转成了udp报文。最后，发包器不是完美的，有部分抓包 的报文

发包器可能无法发送，所以比较 使用wireshark

1.10.0。实况黑屏--显卡支持显示，但是现场仍然无法，那么可能的原因就是有时候现场获取的报文你使用测试工具，在你的PC上可以1、你使用的库和现场不匹配（这个容易排除）2、你的pc和现场pc配置不一样，关键是显卡不一样。检查是否开启硬件加速，另外改为普通品质的图像经常在

或虚拟机上无法

实况，这个问题后续版本会解决，对于之前的版本，大都是由于显卡未开启硬件加速导致；也可能是没有安装显卡驱动；也可能是第 的抓屏

……总之，不管什么原因，使用如下命令即可：cmd中输入dxdiag，在显示中查看，directx是否开启，普通品质对应“directdraw”，高品质对应“direct3d”实况黑屏---总结安装如上步骤如果问题仍没有得到定位，那么说明这个问题有点棘手，请联系研发定位。需要的信息包括：版本信息，客户端日志，客户端的完整抓 括信令）。第

对接黑屏库，哪些decodetag是第 公司自了解了第一部分后，其实我做一个decodetag的总结，哪些decodetag是己的 库：第 公司的 库如下：hikvision-v3npplaysdk-v3hxht_realhikvision-v1crearozte8000dahua-v3dahuazteyaandahua-v1hikvisionchuangxiangweiyeNanzixingwangruijieRuimingxinchanbeierxinTiandyzjbellwenanTDY-SWALLOWzjbell5301chengfengDMA-SWALLOWpqbluesky-zhhxhtlangchi-97HWhanbangbeierhuangheBityaan第

对接黑屏库的decodetag：H3c-v3H3c-v1Guobiaoaproud-onuyaan-v3SonyONVIF1.0ONVIF2.0ONVIF2.1Samsungpanasonic第

对接黑屏如果使用第 的decodetag导致黑屏，那么最好的方法就是1、排除网络2、使用XP_PLAYER_DEMO 器验证。3、找研发卡顿类器，其实卡顿类问题也是很容易定位的，可以使用设置器“流畅性”和“实时性”来有了XP_PLAYER_DEMO验证功能是否有效。案例讲解某局点反馈DC

卡顿、黑屏，在DC上获取报文后开始分析：1、从抓包的data字段中发现第一个字节是80，说明是对方发的是rtp报文案例2、选中一个报文，邮件菜单中选择dec