轉載自:http://tech.lmtw.com/technews/201504/115637.html
【流媒體網】消息：CDN這幾年爆炸式增長，帶寬提速是根源，而HTTP始終還是那個屌樣，因此目前CDN大多是資本性行業，不用多少知識就能干了;直到流媒體粗現，直播咋這么難搞呢?因為它是流媒體，讓我帶你深入淺出看流媒體前世今生，分分鐘二逼變牛逼。
流媒體分為點播和直播，點播已經墮落為HTTP文件了，直播永遠不可能只用HTTP就OK，這是他們的業務差異導致的。流媒體本質上是：現實的圖像，經過編碼器壓縮，持久化為點播文件或者直播流，經過傳輸，在終端解碼和展示。
點播為何屬于HTTP而不是流媒體呢?點播，譬如電影或者錄制的影像，傳輸給觀看的終端時是不變的，一萬個人看一個電影無論什么時候看都是一樣的媒體數據，因此傳輸上直接使用HTTP就可以了。點播的流媒體特征還是有的：
點播的重新編碼，譬如為不同終端輸出不同碼率和尺寸的點播文件，需要媒體知識了。這部分因為使用太廣泛，所以開源屆早就支持得很成熟，ffmpeg對文件重新編碼已經做得很好了。
點播P2P，這個實際上分為客戶端的P2P和web P2P，這個和媒體沒有什么關系，但屬于點播需要做的范圍，沒有現成的方案。(插播廣告：觀止創想已經支持了點播HLS的P2P，現有系統不用修改就可以加上web P2P)
其他的什么分片，DRM，彈幕，分享，多終端轉封裝，文件調度，HTTP API調度，熱點，mp4/flv-range請求，存儲等等。大多都有了成熟的方案，和HTTP文件一樣的技術，要么就是播放器支持，這些和流媒體一毛錢關系都沒有。
這就是為何CDN支持點播支持得很得心應手，幾乎所有的CDN都能直接支持點播分發，甚至一些新興的行業公司，譬如在線教育，對于點播都能自己搞。點播就是HTTP而已，不屬于流媒體范疇。
直播呢，從古老的RTSP到RTMP，HTTP漸進式下載，到HTTP流，到HLS和HDS，到DASH，到私有的websocket。這些不過是直播分發的表象，譬如HTTP直播流就是HTTP點播嗎?不是。HTTP點播本質上是文件分發，而HTTP流是流媒體服務器在內存中將直播的包，打包成RTSP、RTMP、HTTP后發送給每個客戶端。
當然總有例外的，有一個公司嘗試過直播進行點播化，就是時移直播，將直播流錄制成點播文件，然后客戶端請求時總是請求點播。這種私有協議遲早是要死掉的，只有自己的播放器能播，而且得在CDN上部署自己的流媒體;現在這個公司也放棄了自己的“高大上”的私有協議——互聯網的基本精神就是開放標準。可惜中國人很難認同這個理念，牛逼的總喜歡搞私有協議，譬如使用websocket的公司，大多屬于這種類型，牛逼的人太多就是這種結果，一般這種公司也很有錢，譬如某上市的做在線秀場的公司。
目前直播分發有幾個特點：
偏好flv，少用ts：flv標準11頁，ts標準174頁。標準文檔十倍差異，代碼實現起來十倍都不止。因此一般的公司都喜歡flv，pc時代都是flv的天下，什么flv流，flv切片;因為自己寫代碼支持ts比較麻煩，用ffmpeg的代碼又太龐大。直到移動端粗現，現在直播只支持pc的少之又少了，使用flv作為基礎結構的產品要么艱難轉型，要么就掩耳盜鈴說FLV很優雅，HLS太垃圾。
rtmp和hls并存：rtmp一般用于pc-flash播放直播，而hls用于移動端播放。flash能播放hls嗎?前年jwplayer就支持了，可惜是商業版不開源;去年有很多開源的as播放器支持hls。而直播系統，特別是cdn的直播，不會更新這么快，pc端還是rtmp系為主。這個特點是由于平臺客戶端支持的流決定的，并非最佳方案，也不是用戶愿意這么干。
實時流大多使用rtmp：實時流，延遲要求在5秒之內的流，大多使用rtmp協議。pc上可以直接播放，移動端就需要使用ffmpeg解碼播放。有沒有更好的分發方案?實際上http-flv比rtmp更合適，延遲一樣，要求服務器支持，pc能直接播，移動端需要使用ffmpeg，還有個好處是能穿墻。為何cdn大多不支持http-flv直播?因為一般的web服務器支持不了，這是個流媒體問題。
rtsp永遠死不了：這是監控行業的協議，我們都有門戶之見，“RTMP這個爛貨怎么還在互聯網上用呢?RTSP多么優美!”因此有監控行業背景的公司做互聯網業務，都帶著門戶之見不得已將RTSP轉RTMP，而且還要憤憤的說——只不過是不用裝個插件而已。
直播的本質特點，就是需要專門的服務器分發，至少需要直播源站切片HLS后分發。也就是直播需要專門的流媒體服務器，目前開源的流媒體，最古老的是RED5，后面是CRTMPD，風生水起的是NGINX-RTMP，目前最新出的是SRS。
為何RED5不能一統天下?RED5和FMS一樣古老，先行者如果不能放掉自己的光環，遲遲不肯變革，就會被后來者超越。RED5性能是很差，但并非是因為使用了java的原因，這個看看wowza就知道了，商業服務器wowza雖然是個內存殺手，但是支持的并發一點都不含糊。RED5沒有廣泛商用的原因可能一直是一個先行者，祖先的角色。軟件只有快速變化適應需求才能發展，和年紀沒有關系。
那么CRTMPD怎樣?牛逼!使用單進程單線程異步socket，這是和nginx同時代的產物。CRTMFPD是有不少鐵桿粉絲的，以那個時代開始做直播業務的為主。CRTMDP生不逢時，遇到NGINX了，不少NGINX的粉絲是技術牛逼的人物，不然怎么能看懂void*****呢?除了社區的差異之外，CRTMPD沒有支持HLS，倒是支持了RTSP，這就是典型的倒行逆施，互聯網上支持RTSP，大約只有CRTMPD能想到了。
NGINX-RTMP風生水起有幾個很重要的因素。首先2012年開始CDN業務開始快速增長，隨之直播業務也需求暴漲，沒有特別滿意的流媒體服務器;其次，NGINX在HTTP領域絕對是霸主，大家對于NGINX系的熟悉程度很高，便于維護;再次，直播點播使用一套服務器，很有誘惑力，這可以算是“萬金油”效應，很多套服務器搞得焦頭爛額，肯定一套服務器能解決問題;最后，CDN是運維比技術牛逼的行業，運維的信心都是運行出來的，NGINX運行那么良好，那么NGINX-RTMP也肯定不錯。
SRS粗來了，并非石頭縫里蹦粗來個SRS，SRS其實誕生的歷史是：第一個版本實際上是參考NGINX，基本上和NGINX-RTMP同時間點做出來;第二版本是改用ST作為基礎結構，支持RTMP直播點播;第三版本是從CDN出來后重寫的，只支持直播。為何SRS不使用NGINX那種基礎結構，這個和google為何開發golang的原因一樣。SRS和NGINX-RTMP最重要的區別有兩點：其一，使用類似golang的服務器架構;其二，流媒體業務驅動的產品管理，如果可以裝裝逼，SRS是以流媒體業務為主的服務器，而不是以分發協議為主的服務器。
什么是以流媒體為主?流媒體系統的層次包括：網絡層(socket或st)負責傳輸，協議層(rtmp或http)負責網絡打包，封裝層(flv、ts、hls、hds、adts、annexb)負責編解碼數據的封裝，編碼層(h.264和aac)負責圖像壓縮。流媒體服務器的重點在于封裝層，譬如flv、ts、hls、hds、adts和annexb的解析和打包都是自己實現的代碼，參考標準規范，支持完善的封裝轉換和解析。而網絡層因為使用st簡化，使得協議層更簡單，錯誤的概率更低，這個和流媒體的關系就不大了。
什么是以業務為主?“跑起來”和“商用”是兩回事情，商用需要對于流媒體的業務有很好的支持：譬如vhost，這個是計費才有的概念，基于app的也能計費，結果就是要求用戶不能app重復，新增app需要聯系運維，凡是添加app需要聯系運維的cdn，肯定是NGINX-RTMP;譬如日志，出現問題能將流媒體的整個鏈條的日志都能找出來，從邊緣到回源鏈接，到上層節點的日志，一直追溯到推流連接的日志，每個日志都是基于連接的;譬如rtmp+http-flv+hls，國內主要的直播業務都能支持，還有hds可以供那些想裝逼的客戶用;更多牛逼的業務功能就不啰嗦了。
對于流媒體服務器，除非能忘記HTTP服務器，才能看清楚到底為何流媒體和HTTP沒有一毛錢關系，而流媒體在于團隊對于流媒體和服務器的理解，而并非找到一個萬金油服務器能涂抹掉客戶問題。
直播這么多協議，這多么服務器，當前直播重心在哪里?該如何選擇合適的協議?只要問自己三個問題就可以了：
延遲要求，是否要求低于5秒的延遲?如果是硬指標，就只能選擇RTMP或HTTP-FLV流。移動端需要自己編譯FFMPEG支持，無法直接播放。
終端適配，是否要求支持PC和移動端(IOS和Android)?如果需要廣泛支持移動端，HLS是最好的選擇。
節約帶寬，是否要求支持WebP2P?如果需要支持FlashP2P，或者移動端P2P，選擇HLS。
當初有個跨國老牌的流媒體公司，勸說不要使用RTMP了，因為半年時間RTMP就會死掉，DASH會替代所有的流媒體協議。現在2年過去了，RTMP和HLS除了更加爆炸性應用之外，我看死掉的是那些過于技術至上的公司。
如果用一句話說流媒體直播：實時性要求高的用RTMP或HTTP-FLV，其他都用HLS。
協議請參考：https://github.com/winlinvip/simple-rtmp-server/wiki/v2_CN_DeliveryHLS
服務器請參考：https://github.com/winlinvip/simple-rtmp-server/wiki/v1_CN_Compare
關于SRS的架構參考：https://github.com/winlinvip/simple-rtmp-server/wiki/v1_CN_Architecture