转自：http://blog.csdn.net/fengyily/article/details/42557841

本人一直用的是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。

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

[cpp] view plaincopy

1. if (!_pProtocolHandler->InboundMessageAvailable(this, header, channel.inputData)) {  
2.     FATAL(“Unable to send rtmp message to application”);  
3.     return false;  
4. }  

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

[cpp] view plaincopy

1. if (!_pProtocolHandler->InboundMessageAvailable(this, header, channel.inputData)) {  
2.     FATAL(“Unable to send rtmp message to application”);  
3.     //return false;  
4. }  

再次调试，果然灵光。又测试了转推其它类型流媒体服务，我又笑了。。。