转:rtmp 时间戳问题
花了5天时间,终于解决了一个bug,心情非常愉快,憋了这么久,不吐不快。
事情是这样的,前面跟外地一家公司,开发一个二路RTSP音视频合成一路RTMP音视频的设备。设备在公司内运行是好好的,可到了现场,出现直播流畅,录制后点播卡顿的问题。由于设备在外地,调试不方便。只能这边写日志打印代码,那边烧程序调试,于是远程调试的恶梦开始了。远程操作画面卡不说,关键是慢,本来一个几分钟的事情,远程要搞几十分钟。长达5天的远程调试,真是对人的耐性的一种考验。
首先我怀疑的是时间戳不均匀。于是我将发送端的时间戳,接收端的时间戳分别日志成文件,统计,没有发现过大或过小的时间戳。也没有发现累计时间戳和累计到达时间偏差很大。这样能排除时间戳的问题。
其次我怀疑是数据格式的问题。我们这边RTSP的数据源设备和现场的不一样。于是我又写代码,将RTSP下拉的数据保存文件,去掉RTP头,添加SPS、PPS,保存为裸H264文件。数据用VLC播放这个裸H.264文件,结果可以流畅播放,说明视频数据是完整的。再写代码将H264文件分帧并用RTMP协议打包发送直播,FP能流畅直播,录制依然是卡的。开始怀疑我的分帧发送代码是否有问题,于是将我以前录制好的H.264文件拿来,用同样的方法测试,结果直播流畅,录制流畅。同样的代码不同H264文件有不同效果,那么可能是H264文件格式的不同。于是分析h264文件的NAL。NAL等于5的就是关键帧。录制流畅的h264每个关键帧之间的间隔是固定的32,而录制卡顿的H264文件,十几个关键帧连在一起。根据以往经验,这是变码率的H264数据。我的RTMP协议栈并没用支持这种格式。于是开始分析这种变码率的h264格式,在我自己的电脑里面搭建环境调试改写协议栈,轻车熟路,没过多久,我的RTMP协议栈能支持发送这种变码率的H264数据直播了。直播流畅,录制流畅。好像问题攻克了。于是带着高兴的心情,将程序更新到我的远程设备,运行。一看效果,刚开始直播和录制流畅,没过多久就开始卡顿了。和之前卡顿不同的是,卡顿频率降低了,而且FP会反复打印日志NetStream.Buffer.Empty。刚才高兴的心情一下子仿佛回到了解放前。
根据经验,这种情况一般是网络带宽不足,播放端缓存不足,或时间戳过小导致。于是我让在现场的工作的人员测试播放,结果他们在局域网看效果仍然卡顿,排除了带宽不足的问题。然后我增加播放器缓存到5秒,播放依然卡顿,又排除了缓存不足的问题。再然后我将发送端时间戳,接收端时间戳日志到文件,终于发现问题了。发送端时间戳正常,而接收端时间戳出现4000以上的大时间戳。按道理发送30帧每秒的视频,平滑处理后的时间戳应该是33-34。如果是FMS将我的时间戳修改增加了,那么会导致累计时间戳比累计时间大,但结果统计这二个值相差不大。我也没有发现有过小时间戳来中和这个大时间戳,那么累计时间戳是如何保持不变的呢,有一种可能性,丢包了。我将统计的帧数除以时间打印出来发现接收端只有20帧每秒。发送端打印的是30帧每秒。恩,可能是丢包了。我想看看是哪些数据丢了,于是将发送端的数据记录到文件,接收端接收的数据也保存到文件,对比,竟然发现数据总大小一模一样,说明没有丢包。于是我逐帧地对比发送端和接收端的数据,发现接收端有一包里面包含十多个帧的现象。而这种现象出现在接收到一个大关键帧的后面。FMS为什么会将大关键帧帧后面的小参考帧连起来做为一帧呢?这个问题我想了很久,也做了各种各样的实验。修改了多种打时间戳的方法和平滑时间戳的方法,也没有效果。最后,我猜测是否因为音频数据不足导致。因为我知道音频和视频播放不一样,它不会因为时间戳打得快就快放,它按照自己的频率计算时间匀速播放。如果音频数据不足或丢失,那么本来应该和它一起播放的视频帧会快进或跳过。于是我将发送音频部分的日志打印出来,果然发现存放问题,音频数据的环形缓存区满了,导致音频丢包。我为了防止重入,发送视频包的时候,音频不能发送。而且我们是1080P 的视频,视频关键帧有上百KB。我的音频环形缓存长度设置的10个。瞬间导致音频缓存满,然后就是音频数据丢失。于是我将音频环形缓冲长度改为30,日志显示环形缓冲最大不超过20个。小心地将最新的程序更新到设备,看效果,直播依然卡顿。我明明解决了一个BUG,竟然没有效果。神啊,救救我吧,我已经花了4天时间了,早已身心疲惫。
当然,神是不会理我的,这BUG还是要我们程序员自己解决。FP还是打印日志NetStream.Buffer.Empty。于是又来分析时间戳,统计,没有发现过大或过小的时间戳。也没有发现累计时间戳和累计到达时间偏差很大。但是发现累计时间和累计到达时间相比戳抖动比较大。说明时间戳没问题,只是有些包来晚了,然后后来又补上了。这样子好像是远程直播带宽不稳定导致。于是让在现场的工作人员测试直播,效果流畅。再让他们测测录制,也是流畅的。反复测试没出现卡顿,问题终于解决了。心情愉悦。
总结,1,找BUG需要沉下心来,找不到问题不要灰心,一定要充满斗志,否则容易中途放弃不前。 2,判断问题需要准确定位,在一个错误方向上努力完全是浪费时间。3,多做实验,写日志,用数据说话,不要凭空猜测。4,写代码的时候,日志不要多,但处理严重错误的时候还是需要日志一下,方便日后排除错误。不要像我缓冲满了也不printf一下。