本人一直用的是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;
}
再次调试，果然灵光。又测试了转推其它类型流媒体服务，我又笑了。。。