最近在和小伙伴们沟通过程中，碰到了一些问题，有些是非常典型的，很有借鉴意义，所以在此进行部分罗列一下，并针对一些问题给出排查方法和解题思路，希望对于其他音视频开发者有借鉴意义。

1 时间戳问题

客户反馈的门口机被监控平台监控1个小时左右没有视频的问题。

1.1 问题排查

客户反馈一个包，大小为3G+， 用wireshark打开查看，天了个噜，总共325 3874个数据包。要从这个抓包中找到问题点，没有点方法论、不用点手段估计要看到猴年马月了。而客户那边也在等着最终结果，为了最快速分析、定位，以便能够解决该问题，我们几个小伙伴开始了溯源的历程。

尝试用h264工具导出视频，结果电脑直接卡死（原谅一个老员工不想换电脑，还是Intel 7500系列的老古董），卡住了10分钟后，终于把包导出来了，但是用Potplayer播放器播放两个小时是正常的呀。

所以传输数据是正常的，那就排查编码端、传输网络的异常嫌疑了。最有可能的是播放端解码和显示问题了。

1.2 问题原因

经过逐步摸排，发现一个异常点，如下图红线标注的地方：

可以看到在大概1小时12分左右时间戳有了明显的跳转，如果跳转后没有正确解码是不是显示就异常了呢？之后和产品系列的负责人反复沟通，最后确认他们的时间戳是用uint32标识的，那这个大小就是： 0~4294967295，正好符合当前上图中红线标注的地方反转的问题，符合当前的分析情况。

1.3 解决办法

有了这个分析之后，就把这个情况和负责人简单说明，协助他们进行优化，增加时间戳的溢出回绕的保护机制。

整数回绕等方案，网上一大堆，有需要的大家可以自行查阅，这里就不在累述了。

1.4 线程耗时

之后又反馈一个问题：

优化后vlc监控会很卡、抓包也没办法导出成h264

查看抓包，数据都是正常的，导出的包也是正常的，播放器可以播放

但是怀疑的点仍然是在时间戳这个地方，经过代码review发现封包流程和发包流程在一个线程中，导致发包流程时间消耗太大，所以播放端会选择性丢弃视频帧，所以会比较卡

之后将其线程中耗时动作移除到新的线程中，就可以了。

之后咨询了一下Android端的情况，我们本身有保护机制，超过半小时就暂停了，所以不会出现最大值溢出问题。

2 SPS数据解析

2.1 问题描述

在MPP解码播放1080P网络视频流或视频文件，得到的画面大小却是宽为1920像素，高为1088像素！但是初始化解码器选择是1080导致解码底下一条花屏

2.2 原因

1080行格式使用1920×1088像素luma矩阵和960×540色度矩阵进行编码，但最后8行被MPEG-2解码和显示过程丢弃。

是部分软件在实现网络摄像头，H.264协议码流中，计算画面宽高的方式有误，正确应该如下：

# 公式一
Width = (pic_width_in_mbs_minus1+1)16;
Height = (pic_height_in_map_units_minus1+1)16;

但是部分分辨率要用公式二进行计算

#公式二
width = (sps->pic_width_in_mbs_minus1+1) * 16;
height = (2 - sps->frame_mbs_only_flag)* (sps->pic_height_in_map_units_minus1 +1) * 16);

最后修改就是把这部分进行对齐完成修复

3 SIP协商问题

3.1 封包模式不兼容

例如之前反馈的一个问题：R平台和客户cloud APP 视频通话兼容性问题解决

排查了一圈后问题确认了，客户的app支持封包模式mode 1， 我们支持的是mode 2；但是现实情况是： 无论APP呼叫话机，还是话机呼叫APP，服务器反馈给话机的值都是mode 2而给APP的都是mode1;

如果APP呼叫话机，协商的mode2， 所以视频是OK的，但是如果话机呼叫APP，APP期望是mode 1，这个值会给到服务器， 但是服务器还是给话机反馈是mode 2，所以话机就无法解码了。

潮流话机的默认模式就是1，所以不会出现这个问题。

其实正常如果服务器按照被呼叫方的直接给主叫方，这个问题是不会出现的

3.2 和客户服务器兼容

现在又有一个问题：R平台视频通话不兼容 MITEL服务器

初步分析如下：客户的服务器不支持我们的封包模式，导致协商时候message body都不见了。这类问题就是因为协商时候双方支持的类型不一致，导致无法协商成功，而服务器做了特殊处理，协商不成功的部分就直接移除，那messagebody就直接删除了（这台服务器好暴力，或者开发者太懒惰），所以现象就是看不到任何有用信息了。

3.3 服务器不转发message body

查看SDP中其他视频数据，发现一个新的问题点：客户选择H265和H264两种编码方式，但是PayloadType却是一样的，104

之后导出通话双方的配置项，发现确实是这样的，通话时协商选择H265， 但是主叫方没有265选项，本地按照相同配置模拟一下，视频可以建立起来，但是是H263的编码格式。

之后重新沟通了一下，并尝试用Linephone进行模拟，发现：确实是服务器有问题，将SDP的Message Body移除掉了。这个和最初的分析是一致的。

正常情况下一旦没有Message Body就没办法确认编解码格式，所以无法建立视频通话。

竞品可以是因为在反馈invite ACK时候，直接反馈所有默认的音视频格式，这样选择的主动权又回归到主叫方，而不是按照协商的方式进行选择了（所以说服务开发者偷懒了，同时也感叹友商耍无赖呀）。

如下图：发起invite是携带的sdp数据：

会200OK时携带的数据：

因此需要和客户说明当前情况，同时增加对应的兼容性。

以上是最近发现的问题点，暂时做一些汇总，防止之后再犯。

欢迎点赞、评论、关注、转发；随时探讨，持续输出。