如何处理监控类直播中遇到的奇葩问题

一、问题背景

问题表现：近期一客户用网络摄像头推流到观止云，但推上来的视频总是一卡一卡的，排除了我方CDN自身问题后，我们把排查视线转移到客户推上来的rtmp流。

需要的工具：srs_rtmp_dump、tcpdump、wireshark

客户推流工具：网络摄像头，推送RTMP流

二、问题排查过程

工具：srs_rtmp_dump，srs_rtmp_dump的语法如下：

./srs_rtmp_dump -r url [-o output] [-s swfUrl] [-t tcUrl] [-p pageUrl] [-C conndata] [–complex] [-h]

常用参数：

最简单的用法：

./srs_rtmp_dump -r rtmp://127.0.0.1:1935/live/livestream -o output.flv

当然也可以使用重定向符号”>”把输出内容输出到文本文件。

OK，let’s go

返回如下结果：

从时间戳上来看，貌似看不出什么问题。但总感觉哪里怪怪的，你看出什么问题来了吗？

 

 

工具：tcpdump wireshark

用到的tcpdump的参数：

使用如下命令开始抓包：

用wireshark开始分析数据：

看序号为545的这个包和之前的几个包，时间戳是正常的，545包的时间戳是：7855535，我们继续往下看。

序号547的包时间戳是16777215，（此处省略一个字），时间戳跳变了，咱继续。

这几个包有问题，然后呢？

然后时间戳恢复了，从出问题的时间戳到恢复的时间戳，时间差大约0.07s。继续看看下面的包，重复该过程。

OMG，大坑啊，真相大白了，问题就是这个时间戳跳变引起的卡顿！

但是，处理又怎么处理呢？客户辛辛苦苦淘的二手高端大气的摄像头总不能扔了吧？开门，放程序猿……

下面是从给客户反馈问题原因到解决问题过程的对话：

虽然程序猿解决这个问题也就不到一个小时，但是对于客户来说可是解决了大问题。

三、结语

以上实例讲述的过程其实在直播推流环节可能会经常遇到的问题，最主要原因是推流工具终端的不规范，其它还有诸如sps的问题、音视频混合非单增问题等，观止云团队都会基于自身在直播领域的运维和服务经验，对其一一扼杀。

推流环节在整个直播过程中其实只是冰山一角，后续观止云运维GG们会陆续为大家实例分享直播流程中遇到的更多奇葩问题以及解决办法。我们不试图得到您的掌声，惟愿安静的抚慰每一个直播人操劳的心，您的顺手转发就是给我们最大的慰藉。