對業內人士來說流媒體平台這個詞一定不陌生，圈子以外的朋友可能只知道個基本的概念，如何選擇適合
自己的流媒體平台可是個很大的話題，說道細處，三天三夜都說不完。今天結合自己的經歷的一些案例，從宏觀
上跟大家分享下我的心得體會，希望幫助到有需要的朋友。
首先從協議上說說幾種常見的流媒體類型，主流的流媒體類型有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_2/
視頻下載地址： http://www.chungen90.com/?news_3/