C++ rtmp ZeroC ICE

海阔天空 张翼飞翔

我的学习日记
随笔 - 75, 文章 - 2, 评论 - 126, 引用 - 0
数据加载中……

花了5天时间,终于解决了一个bug,心情非常愉快,憋了这么久,不吐不快

(原创) 
花了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一下。

posted on 2011-12-06 16:37 ZhangEF 阅读(11616) 评论(13)  编辑  收藏 所属分类: C/C++rtmp

评论

# re: 花了5天时间,终于解决了一个bug,心情非常愉快,憋了这么久,不吐不快  回复  更多评论   

写的太好了,受益匪浅
2012-02-16 09:56 | wxg0130

# re: 花了5天时间,终于解决了一个bug,心情非常愉快,憋了这么久,不吐不快  回复  更多评论   

发送端时间戳正常,而接收端时间戳出现4000以上的大时间戳。按道理发送30帧每秒的视频,平滑处理后的时间戳应该是33-34。如果是FMS将我的时间戳修改增加了,那么会导致累计时间戳比累计时间大,但结果统计这二个值相差不大

这个时间戳是H264的IBP帧的时间戳还是RTMP包的时间戳呢?如果是264的时间戳不是连续增加的吗?33-34是rtmp包的相对时间戳吗?rtmp包的时间戳有什么作用呢,接触不多,请赐教
2012-02-16 10:19 | wxg0130

# 回复:wxg0130   回复  更多评论   

1我指的是RTMP包的时间戳。
2发送的rtmp包时间戳是相对时间戳。
3rtmp时间戳是用来做音视频同步的。
2012-02-23 14:47 | ZhangEF

# re: 花了5天时间,终于解决了一个bug,心情非常愉快,憋了这么久,不吐不快  回复  更多评论   

写的很好,给我们程序员很大的启发。有一个问题想请教一下博主。我做的也是获取到视频,经过X264编码,通过RTMP协议发送到RED5,可是发送的视频用flash播放器出现黑屏,但是时间正常走着。除了flash 播放器外,其他的播放器都可以播放,请赐教一下,这是怎么回事
2012-10-31 11:12 | 阿日月

# re: 花了5天时间,终于解决了一个bug,心情非常愉快,憋了这么久,不吐不快  回复  更多评论   

你好,我将dm368编码的h264视频裸流保存成文件,但是vlc打开后发现播放速度是原来的两倍,请问知道是为什么吗?
2013-01-09 10:35 | AMAM

# re: 花了5天时间,终于解决了一个bug,心情非常愉快,憋了这么久,不吐不快[未登录]  回复  更多评论   

@AMAN
编码的时候,输入正确帧率就可以了。如果不输入帧率,编码后的裸H264 文件VLC会用默认帧率播放,默认好像是25还是30的。如果你实际压缩是15帧每秒,按照默认帧率播放就会快放了。
2013-02-11 17:39 | ZhangEF

# re: 花了5天时间,终于解决了一个bug,心情非常愉快,憋了这么久,不吐不快  回复  更多评论   

请问大神,我写的实现流播放器。在开发工具下直接运行,画画是不卡的,但是当我打包出来,安装播放, 画画就变得一卡一卡的?这是为什么啊?
2013-08-13 11:04 | 黑熊

# re: 花了5天时间,终于解决了一个bug,心情非常愉快,憋了这么久,不吐不快  回复  更多评论   

请教一下,如何添加SPS、PPS,将数据保存为裸H264文件?如能告知,万分感谢!
2013-08-16 09:56 | lxdlut

# re: 花了5天时间,终于解决了一个bug,心情非常愉快,憋了这么久,不吐不快  回复  更多评论   

@lxdlut
每个关键帧前面00000165开头前添加SPS,PPS,然后存成文件即可
2014-07-30 15:29 | alucard

# re: 花了5天时间,终于解决了一个bug,心情非常愉快,憋了这么久,不吐不快  回复  更多评论   

难不成是大神张总?
2014-11-28 16:52 | 付总

# re: 花了5天时间,终于解决了一个bug,心情非常愉快,憋了这么久,不吐不快  回复  更多评论   

@付总
真的是你吗?毕业这么多年,在这里遇见,太巧了。
2015-01-07 11:51 | ZhangEF

# re: 花了5天时间,终于解决了一个bug,心情非常愉快,憋了这么久,不吐不快  回复  更多评论   

受益匪浅
2015-01-28 23:20 | wxl

# re: 花了5天时间,终于解决了一个bug,心情非常愉快,憋了这么久,不吐不快  回复  更多评论   

张总,我现在在cnblogs上混
2015-02-26 21:32 | 付总