摘要:网络摄像头监控形态上其实也是直播中的一种，虽然目前量不算大，但是未来发展可期。此类应用中，客户推流设备一般是网络摄像机（即能推送RTMP流的高清摄像头），由于市面上的网络摄像头品牌多，功能杂，难免在推流过程中出现各种奇葩问题，影响观看效果。今天观止云的运维GG就要实例分享如何快速解决网络摄像头推流中会遇到的问题。
一、问题背景
问题表现：近期一客户用网络摄像头推流到观止云，但推上来的视频总是一卡一卡的，排除了我方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]
常用参数：
-r： ramp流的URL。
-o: 输出到flv文件。
-h：查看帮助。
最简单的用法：
./srs_rtmp_dump -r rtmp://127.0.0.1:1935/live/livestream -o output.flv
当然也可以使用重定向符号”>”把输出内容输出到文本文件。
OK，let’s go
命令行输入：# ./srs_rtmp_dump -r rtmp://video.abc.com/live/class1
返回如下结果：
从时间戳上来看，貌似看不出什么问题。但总感觉哪里怪怪的，你看出什么问题来了吗？
用到的tcpdump的参数：
-w：把抓包信息写到t1.pcapip host：指定抓主机192.168.1.179的数据包
tcp port 1935：抓tcp协议1935端口的数据包
ip host 192.168.1.219 and tcp port 1935：抓取与192.168.1.179主机的tcp 1935端口通讯的数据包。
使用如下命令开始抓包：
#tcpdump -w t1.pcap ip host 192.168.1.219 and tcp port 1935
用wireshark开始分析数据：
看序号为545的这个包和之前的几个包，时间戳是正常的，545包的时间戳是：7855535，我们继续往下看。
序号547的包时间戳是16777215，（此处省略一个字），时间戳跳变了，咱继续。
这几个包有问题，然后呢？
然后时间戳恢复了，从出问题的时间戳到恢复的时间戳，时间差大约0.07s。继续看看下面的包，重复该过程。
OMG，大坑啊，真相大白了，问题就是这个时间戳跳变引起的卡顿！
但是，处理又怎么处理呢？客户辛辛苦苦淘的二手高端大气的摄像头总不能扔了吧？开门，放程序猿……
下面是从给客户反馈问题原因到解决问题过程的对话：
虽然程序猿解决这个问题也就不到一个小时，但是对于客户来说可是解决了大问题。
三、结语
以上实例讲述的过程其实在直播推流环节可能会经常遇到的问题，最主要原因是推流工具终端的不规范，其它还有诸如sps的问题、音视频混合非单增问题等，观止云团队都会基于自身在直播领域的运维和服务经验，对其一一扼杀。
推流环节在整个直播过程中其实只是冰山一角，后续观止云运维GG们会陆续为大家实例分享直播流程中遇到的更多奇葩问题以及解决办法。我们不试图得到您的掌声，惟愿安静的抚慰每一个直播人操劳的心，您的顺手转发就是给我们最大的慰藉。
