NVR对接三方相机预览黑屏问题案例

一、 问题现象
【问题现象】NVR接入三方相机,通道状态显示在线,但本地、web预览显示黑屏。更换H.264，H.265均预览黑屏，且NVR侧的萤石云手机APP预览报错260025。
【现场拓扑】现场拓扑如下
（1） IPC使用onvif协议添加至NVR，NVR通过光猫跨公网注册至萤石云。
（2） IPC也通过光猫跨公网注册至萤石云。
（3） IPC及NVR在同一局域网下

图1.1：网络拓扑
二、 问题排查过程
此问题可以归类与三方相机对接问题，onvif的本质就是HTTP协商+RTSP取流，所以可以使用VLC同时取相机流测试。
1、NVR异常时使用VLC取流测试
使用VLC取预览流测试结果如下
（1）时间进度条正常走动，但VLC不显示画面。
上述的测试证明相机发流存在问题，但仍需进一步定位问题原因。
2、简化网络环境
（1）因相机侧单独添加到萤石云上，同时又被添加至NVR，问题本质是NVR无法预览相机。
（2）所以可先删除萤石云上单独添加的相机，只保留NVR这一路取流，排除其他可能的影响条件，进一步排查问题。
（3）当萤石云APP上删除ipc后，此时发现，NVR本地、web预览正常
3、抓包分析
所以目前需要找出IPC单独添加到萤石云APP后NVR预览IPC画面显示黑屏的原因。
（1）异常期间抓包分析。

图2.1：异常期间抓包分析
从图2.1可看出，异常期间相机是与录像机之间是正常协商且正常推流的，而且并无丢包现象，此时排除了相机取流路数上限以及网络环境问题。但是实际上录像机预览依然黑屏。
（2）异常情况下与正常情况下抓包追踪流对比。

图2.2：异常期间流追踪

图2.3：正常期间流追踪
由图2.2及图2.3可看出，设备侧正常及异常情况下 RTSP协商的码流类型均为H.264。
由上两图可看出，设备侧在RTSP报文协商阶段并无问题。
（3）异常情况下与正常情况下相机推流对比。

图2.4：异常推流报文

图2.5：正常推流报文
通过Payload字段分析
（1） 异常期间设备侧收到的码流实际为H.265，但是由图2.2可得出RTSP协商时码流协商类型为H.264。
（2） 正常期间设备收到的码流类型为H.264，从图2.3也可得知RTSP协商时码流协商类型为H.264。
三、 问题原因
萤石相机单独添加萤石云后，主机RTSP取流协商推流为H.264实际推流为H.265，导致NVR解码失败，预览黑屏。
PS：
（1）H.264格式Payload字段前两位一般为 67/68
（2）H.265格式Payload字段前两位一般为 40/42/44
四、 附录
1.H.265的码流格式
1、H.265一个图像序列的组成：VPS+SPS+PPS+SEI+一个I帧+若干个P帧。VPS、SPS、PPS、SEI、一个I帧、一个P帧都可以称 为一个NALU。
2、H.265的NALU结构：开始码+NALU头+NALU数据
（1）开始码大小为四个字节，是一个固定值00 00 00 01（十六进制），标识一个NALU的开始。
（2）NALU头大小为两个字节，共16位，第1位值为0，第2-7位为NALU的type位（共6位），标识当前NALU的类型 ，第8-15位值为0，第16位值为1。
（3）NALU数据为编码器编出来的图像信息或图像数据。
3、六种类型的NALU
（1）VPS（视频参数集）：NALU头值为0x40 01（十六进制），NALU头type位值为32（十进制）。
（2）SPS（序列参数集）：NALU头值为0x42 01（十六进制），NALU头type位值为33（十进制）。
（3）PPS（图像参数集）：NALU头值为0x44 01（十六进制），NALU头type位值为34（十进制）。
（4）SEI（补充增强信息）：NALU头值为0x4e 01（十六进制），NALU头type位值为39（十进制）。
（5）I帧：NALU头值为0x26 01（十六进制），NALU头type位值为19（十进制）。
（6）P帧：NALU头值为0x02 01（十六进制），NALU头type位值为1（十进制）。
H.265 UDP码流payload字段分析例：
Payload:40:01:0c:01:ff:ff:21:60:00:00:03:00:00:03:00:00:03:00:00:03:00:96:ac:09
40:01—（二进制）---- 0100 0000 0000 0001
第一位：0
NalType：100 000 》32 =》VPS
LayerID：0 0000 0》0
TID：001 ==》1

4、H.265的NALU打包成RTP包的模式（下面是用到的两种模式）
（1）一个NALU打包成一个RTP包，只需要在一个12字节的RTP包头后添加去掉开始码的NALU即可 （此问题中设备使用的方式）
（这种模式在一个NALU的大小小于MTU时使用）。
（2）一个NALU打包成几个RTP包（FUs模式），在12个字节的RTP头后面有两个字节的PayloadHdr和一个字节的FUheader。PayloadHdr的值等于NALU头的type位改为49（十进制）后的值，FUheader第1位标记RTP包是否为NALU的第一片，第2位标记RTP包是否为NALU的最后一片。后6位是NALU头的type位。
SDP参考：
h.265的VPS/SPS/PPS
（1）与分辨率有关
（2）与帧率无关(与帧率是否有关主要看sps中某个字段的值，
（3）与N/P制无关
1、4M
Payload: 40010c01ffff016000000300b00000030000030099aa0240
Payload: 420101016000000300b00000030000030099a001402005a1636aa4932f90
Payload: 4401c0f2f03c90
2、4M_4x3
Payload: 40010c01ffff016000000300b00000030000030099aa0240
Payload: 420101016000000300b00000030000030099a001202006c1636aa4932f90
Payload: 4401c0f2f03c90
3、3M
Payload: 40010c01ffff016000000300b00000030000030099aa0240
Payload: 420101016000000300b00000030000030099a00100200601636aa4932f90
Payload: 4401c0f2f03c90
4、1080P
Payload: 40010c01ffff016000000300b0000003000003007baa0240
Payload: 420101016000000300b0000003000003007ba003c08010e58daa924cbe40
Payload: 4401c0f2f03c90
5、960P
Payload: 40010c01ffff016000000300b0000003000003007baa0240
Payload: 420101016000000300b0000003000003007ba00280803c1636aa4932f9
Payload: 4401c0f2f03c90
6、720P
Payload: 40010c01ffff016000000300b0000003000003005daa0240
Payload: 420101016000000300b0000003000003005da00280802d1636aa4932f9
Payload: 4401c0f2f03c90
7、D1
Payload: 40010c01ffff016000000300b0000003000003005aaa0240
Payload: 420101016000000300b0000003000003005aa00582009058daa924cbe4
Payload: 4401c0f2f03c90
8、CIF
Payload: 40010c01ffff016000000300b0000003000003003caa0240
Payload: 420101016000000300b0000003000003003ca00b0804858daa924cbe40
Payload: 4401c0f2f03c90
2.H.264的码流类型判断
（1）NAL的封装方式：
    NAL是将每一帧数据写入到一个NAL单元中，进行传输或存储的
    NALU分为NAL头和NAL体
    NALU头通常为00 00 00 01，作为一个新的NALU的起始标识
    NALU体封装着VCL编码后的信息或者其他信息
（2）NAL的封装过程：
I帧、P帧、B帧都是被封装成一个或者多个NALU进行传输或者存储
每一个I帧开始之前也有非VCL的NAL单元，用于保存其他信息，它们是PPS、SPS
  PPS（Picture Parameter Sets）：图像参数集
  SPS（Sequence Parameter Set）：序列参数集
  在实际的H.264数据帧中，往往帧前面带有00 00 00 01 或 00 00 01分隔符，一般来说编码器编出的首帧数据为PPS与SPS，接着为I帧，后续是B帧、P帧等数据。
H.264的判断方法可以参考H.265，注意报文中如下帧的参数即可。
SPS：0X67、PPS:0X68、I帧：0X65、P帧：0X41