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