CRtmpServer转推流到Nginx Rtmp及SRS(SimpleRtmpServer)的经历

作者分享了从CRtmpServer转向使用SRS和Nginx搭建RTMP服务的经验,遇到的问题及解决方案。在使用Nginx时遇到转推流媒体服务失败,最终通过修改CRtmpServer代码解决了问题。

本人一直用的是CRtmpServer服务,在CRtmpServer服务中根据自已的想法也加入了许多功能,如通过http接口来加载配置等,苦于不支持HLS,自已添加ts分片水平又有限,思来想去决定借助SimpleRtmpServer的HLS功能。说干就干,马上查找相关资源,下载、解压一一蹴而就,SRS顺利搭好,比想像中的要简单很多。

SRS服务搭建好后,直推测试成功,在配置CRtmpServer转推流时,SRS的流播放不出,查看日志发现报了个tcUrl不能为空的异常,于是想到应该是CRtmpServer在转推时没有传入tcurl的参数,查看CRtmpServer的源代码,定位到转推的位置,跟综下来确认tcUrl为空,了解了tcUrl的格式,与targetUri是一致,于是将targetUri的值赋给tcUrl,测试顺利通过,就是这么简单,但是,经过一段时间跑下来发现SRS好像不太稳定,也许是对它不太了解。也许看到大家都在用Nginx的HLS,于是又有了将SRS换成Nginx的想法。

在搭建Nginx Rtmp服务时参考的是前辈留下的nginx搭建支持http和rtmp协议的流媒体服务器之一、二、三,由于是第一次在Nginx中添加nginx-rtmp-module模块,感觉和SRS的相比相对烦锁,很多的依赖包要么对版本依赖性较大,要么干脆链接打不开。总的来说整个流程下来搭建还算顺利。

Nginx的配置之前一直用的是它的反向代理及前端Cache,配置起来也得心应手,很快便可以独立使用了,但我搭建Nginx的目的是想用来做RTMP的边缘,提供RTMP以及HLS的播放。在测试时,同样也遇到了CRtmpServer转推至Nginx时不成功,在Nginx 日志中也没发现什么异常,与直接推送相比,发现PUSH的连接,成功然后马上又被断开,经过反复的比较,直推是连接成功后便有创建流、发布流的日志,如下:

2015/01/09 17:13:12 [info] 6587#0: *8 client connected '10.22.22.245'
2015/01/09 17:13:12 [info] 6587#0: *8 createStream, client: 10.22.22.245, server: 0.0.0.0:1936
2015/01/09 17:13:12 [info] 6587#0: *8 publish: name='snh48_live_640_360' args='' type=live silent=0, client: 10.22.22.245, server: 0.0.0.0:1936

转推的日志中并没有createStream与publish的相关日志,便怀疑会不会是CRtmpServer本身的问题呢?为了验证,马上又开启了CRtmpServer进行本地的调试,发现多了一条错误日志,内容为:

basertmpprotocol.cpp:799:BaseRTMPProtocol::ProcessBytes:Unable to send rtmp message to application。

也是就是这玩意在做怪,迅速找到这片代码:

						if (!_pProtocolHandler->InboundMessageAvailable(this, header, channel.inputData)) {
							FATAL("Unable to send rtmp message to application");
							return false;
						}

分析后,估计是CRtmpServer对Nginx返回的消息不被支持,但也不想再去看Nginx的框架,于是想法大胆的直接将return false注释掉跑跑看。

						if (!_pProtocolHandler->InboundMessageAvailable(this, header, channel.inputData)) {
							FATAL("Unable to send rtmp message to application");
							//return false;
						}
再次调试,果然灵光。又测试了转推其它类型流媒体服务,我又笑了。。。


SRS(Simple Rtmp Server)的定位是运营级的互联网直播服务器集群,追求更好的概念完整性和最简单实现的代码。 • 运营级: 商业运营追求极高的稳定性,良好的系统对接,以及错误排查和处理机制。譬如日志文件格式,reload,系统HTTP接口,提供init.d脚本,发,码,边缘回多源站,都是根据CDN运营经验作为判断这些功能作为核心的依据。 • 互联网: 互联网最大的特征是变化,唯一不变的就是不断变化的客户要求,唯一不变的是基础结构的概念完整性和简洁性。互联网还意味着参与性,听取用户的需求和变更,持续改进和维护。 • 直播服务器: 直播和点播这两种截然不同的业务类型,导致架构和目标完全不一致,从运营的设备组,应对的挑战都完全不同。两种都支持只能说明没有重心,或者低估了代价。 • 集群: FMS(AMS)的集群还是很不错的,虽然在运营容错很差。SRS(Simple Rtmp Server)支持完善的直播集群,Vhost分为源站和边缘,容错支持多源站切换、测速、可追溯日志等。 • 概念完整性: 虽然代码甚至结构都在变化,但是结构的概念完整性是一直追求的目标。从SRS(Simple Rtmp Server)服务器,P2P,ARM监控产业,MIPS路由器,服务器监控管理,ARM智能手机,SRS(Simple Rtmp Server)的规模不再是一个服务器而已。 • 简单实现: 对于过于复杂的实现,宁可不加入这个功能,也不牺牲前面提到的要求。对于已经实现的功能的代码,总会在一个版本release前给予充分的时间来找出最简答案。不求最高性能,最优雅,最牛逼,但求最简单易懂。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值