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

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 数据解析

https://blog.csdn.net/GerZhouGengCheng/article/details/107239415

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 时携带的数据：

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

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

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