如何選擇合适的流媒體平台

        對業内人士來說流媒體平台這個詞一定不陌生，圈子以外的朋友可能隻知道個基本的概念，如何選擇适合

自己的流媒體平台可是個很大的話題，說道細處，三天三夜都說不完。今天結合自己的經曆的一些案例，從宏觀

上跟大家分享下我的心得體會，希望幫助到有需要的朋友。

      首先從協定上說說幾種常見的流媒體類型，主流的流媒體類型有rtsp服務、rtmp服務、Hls服務還有就是

GB28181。  

      我了解到的以rtsp協定作為流媒體分發服務的并不多。很多錄影機标稱支援rtsp協定，實際就是内置一個

rtsp服務友善使用者以rtsp協定擷取錄影機輸出的音視訊流。通過抓包可以發現很多錄影機内置的rtsp服務是通過

live555實作的。早起的live555性能很一般，如今的live555已經更新更新，性能如何不敢胡亂評論。早起live555

性能盡管很一般，作為IP Camera的服務，性能上可以滿足要求。網絡帶寬的原因，很少人會大并發通路 IP

Camera。基本都會另建一流媒體服務作為分發伺服器，流媒體服務隻從IP Camera取一次流，以rtsp協定方式。

通過rtsp協定取流有哪些優點呢？首先想到的是低延時，延時對實時流媒體來說無疑是個非常重要的名額，的确

延時友善rtsp協定可以到很好，到底有多好，要區分區域網路跟公網，後面說道其他協定時再一起說。rtsp協定的

另一個優點是音視訊資料傳輸在傳輸層有多個協定類型供選擇，分别是udp，tcp,udp_multicast（多點傳播）。udp

與tcp如何選擇，這跟實際的網絡環境有關，也跟需求有關。比如說需要上明确規定不能出現一點花屏，如網絡

環境還算可以（偶爾出現抖動)可以選擇tcp作為音視訊資料傳輸方式，如果網絡很糟糕，用tcp的結果隻能是越來

越堵，不能從根本上解決問題。如果需求對延時要求非常高比如要求延時低于200ms，優先選擇udp，選擇udp

帶來的問題是網絡出現抖動時視訊包丢失以後會出現花屏現象。花屏是很多客戶是接受不了的，怎麼來解決這個

問題，大部分情況下丢棄掉有缺失的視訊幀即可。在網絡抖動的情況視訊畫面出現瞬間卡頓大部分客戶是可以接

受的。當然也有少部分的客戶不希望看到視訊出現瞬間的卡頓，能不能做到？這個要視情況而定，主要的影響因

素還是網絡。udp_multicast(多點傳播)傳輸方式并不是所有的網絡環境都支援，多級交換機網絡需要交換機自身支援

網絡。udp_multicast傳輸有什麼好處呢？好處便是節省帶寬，接收從IP Camera 到交換機之間的帶寬多使用者同時

請求情況下從IP Camera 到交換機實際隻取一次流。

       很多直播、點播平台選擇rtmp服務作為流媒體平台的核心服務。Rtmp 服務有哪些有優點呢？低延時算時一個

優點，公網下如網絡流暢，rtmp可以做到1S左右延時，很多應用場合1S延時已經滿足需求（如果追求最低當然rtmp

不是最佳的選擇，可以選擇rtsp協定，傳輸層選擇udp協定）。另一個優點是PC端 網頁播放。PC端網頁播放隻要嵌

入Flash即可，浏覽器的相容性很多，不要為插件的相容性煩惱。rtmp協定傳輸層采用的是tcp協定相較人rtsp協定

靈活性不佳。特别是網絡延時高的情況下不建議使用rtmp協定。目前開源的rtmp服務有CrtmpServer，SRS,Nginx

Rtmp等等。本人用的最多的是CrtmpServer，CrtmpServer隻是簡單實作rtmp服務功能 即接收前端主動推流，當有

用戶端請求音視訊流時将緩存的音視訊流推給請求者。這個服務實際是單線程操作。一般的安防領域CrtmpServer是

性能足以滿足要求。比如在window系統下CrtmpServer單台服務可以支援500路以上，Linux系統會更高（linux系統

上限未實際驗證，隻是從IO模型上得出的結論）。SRS,Nginx Rtmp服務由于沒有在實作的環境中驗證，并發量能到

多少不能确定，大量的博文顯示二者的效率都很高，更人心動的是這兩個服務的附加應用更多。很多剛開始接觸流媒

體的朋友更鐘情于SRS,NginxRtmp。我為什麼選擇CrtmpServer 原因之一是接觸的早，原因之二是我不需要服務的附

加應用，所有的應用都可以自己的方式，按自己思路跟需求設計，在别人的模式下往往受到很多限制。CrtmpServer

我用的也隻是協定部分，rtmp協定相較其他協定還是複雜很多，參考已有的且穩定運作的實作還是要省一些時間。至

于視訊源的管理，以及客戶請求連結的管理并不使用CrtmpServer那一套，畢竟單線程的管理模式不通用，也不好用。

       Hls服務是最為簡單的一種服務，我說的簡單指的是協定。Hls服務本質上是Http 服務+TS流，當服務接收到使用者

請求音視訊時服務将本地的切片（小的TS檔案）以Http的方式回發給請求者。切片檔案的大小以及時間的長短可以根據

需求設定，每次發送哪個切片由一個字尾為m3u8的索引檔案控制。人們經常說的m3u8格式實際就是指Hls流。Hls流天

生的缺陷是延時大，傳輸層隻能采用tcp。從性能說相較其他的服務并沒有優勢，那Hls流的優勢在哪裡?隻有缺陷沒有優

勢很快會被淘汰。Hls流最大的優勢是移動端的相容性。Hls流很容易實作在移動端網頁播放，不管是IOS還是Android。

我一直覺得如果移動端友好支援flash，Hls流基本沒什麼用武之地。很多客戶的需求都是IOS手機能看，Android手機能

看，而且不希望是在App中播放，大部分都希望直接在網頁内打開視訊。作為客戶并不關心技術，隻關心效果，他們要

的是簡單友善。曾有一個客戶提了一個需求就是”讓Hls走天下“：他在國外弄了一台伺服器希望我們通過流媒體技術将他

的視訊節目推送到該伺服器并釋出一個視訊流位址，他的客戶可以直接在手機網頁端打開我們釋出的位址觀看他們的節

目，另外他要求使用Hls流。一聽到伺服器在國外，首先想到的是延時。最簡單的測試方法：長時間ping遠端伺服器，延

時基本在180ms左右。我們告訴客戶伺服器延時太大無法用Hls流實作，客戶答複延時大點沒有關系，能正常播放就行。

客戶的了解很直白，ping延時大點，多緩沖點不就可以了嗎？我們可以對客戶Say No 但決不能說客戶無知，畢竟術業有

專攻。退一步說客戶什麼都清楚還要我們幹嘛呢？最後我們給客戶的答複是可以将伺服器放在國内，或者另選視訊傳輸協

議。客戶說服務一定要放在國外且一定要用Hls流，我們最後的答複是實作不了。Hls流協定實作方式并不高明，性能也很

一般卻在業内圈了很多使用者其原因歸根結底是協定的制定及推廣者擁有很大的客戶群體。

      GB28181是國内專家拟定的流媒體通信協定，協定本身算是SIP的子集。2011年釋出了GB28181第一個版本，2014

年有了增補版本。開發基于GB28181的流媒體服務可以借助于開源庫PJSIP或者是OSIP。迄今為止個人覺得GB28181協

議還有很多改善的空間，但這并不會影響GB28181逐漸統一國内流媒體平台市場。

　　如需交流，可以加QQ群1038388075，766718184，或者QQ：350197870

 　　部落客提供Ffmpeg、GB28181視訊教程 播放位址： http://www.iqiyi.com/u/1426749687

　　源碼及Demo下載下傳位址：http://www.chungen90.com/?news_34/

　　視訊下載下傳位址：      http://www.chungen90.com/?news_33/