整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
昨晚公開課程的課題：【HTML5開發流媒體視頻在線直播系統】
而這項技術現在應用的也很廣泛，比如現在一些證券公司流行的在線開戶驗證系統，還有現在很火的直播平臺，而在以后隨著HTML5的應用比重慢慢增大，這些最新潮的技術也會隨之火熱，當然學會這些技術對于找工作來說的幫助還是很大的。
需要昨晚的HTML5開發流媒體視頻在線直播系統視頻的請點擊關注查看置頂文章哦！
在線直播效果圖
Content 】
第一篇章 流媒體原理
1.1 流媒體概念
1.2 流式傳輸特點
1.3 流媒體系統構成
1.4 流媒體涉及技術
1.5 流媒體應用
1.6 國內外大型流媒體系統
1.7 總結
流媒體相關術語
第二篇章 流媒體系統
2.1 編碼工具
2.2 流媒體服務器
2.3 CDN分發網絡
2.4 網絡協議
2.5 播放器
總結：從一個直播APP看流媒體系統的應用
一套大規模的流媒體系統，由編碼工具負責對音視頻文件編碼壓縮（h.264/h.265/VP9/AAC等）；由流媒體服務器負責對數據包進行容器封裝（flv/ts等）以及負責網絡協議打包（RTMP/HTTP等）；由CDN網絡進行全網分發；由播放層負責對圖像進行解碼顯示（FLASH/VLS/VIDEO JS等）。流媒體系統所需的核心組件包括：
（1）編碼工具：用于流媒體文件生成的編碼工具
（2）流媒體服務器：用于控制、傳送流媒體數據的流媒體服務器
（3）CDN網絡：用于支撐流媒體的全網分發網絡
（4）網絡協議：用于支持特定的流式傳輸的網絡協議
（5）播放器：各操作平臺用于顯示流式數據的播放器
本篇內容將對上述5個環節做一個整體性論述，由于本系列分享著重討論流媒體傳輸分發，所以在后續文章不會再講編碼和播放兩個端上的環節。本篇對編碼和播放將稍微展開討論，其它3個環節只簡單提及，后續將分章詳細討論。本篇最后將給出一個實例，讓大家能直觀的看出一個完整的流媒體系統各環節是如何運用到直播系統中。
2.2 流媒體服務器
流媒體服務器簡單來說就是直接向客戶端響應流式連接（如RTMP/RTSP等），返回流媒體數據（打包在RTMP等流式協議中的flv/ts等數據）的服務器程序。流媒體服務器直接承擔流媒體數據的輸出，是整個流媒體系統的核心，它的功能、性能、運行支撐能力直接決定了一個大型流媒體系統的健壯程度。
和編碼器一樣，一套工業級的流媒體服務器所包含的內容是相當復雜的，不過當下市面上也有不少優秀的商用或開源的流媒體Server。我們在搭建流媒體平臺時大可以直接按需選擇其中一款即可。這倆面需要了解的，一是流媒體服務器是干什么的，二是目前市面流媒體服務器有哪些，三是選擇一款流媒體服務器需要衡量哪些方面。
（1）流媒體服務器原理
通俗一點來講，流媒體服務器就是能夠傳輸RTMP/RTSP等實時流式協議的服務端程序，流媒體服務器接收媒體數據后，對媒體數據進行容器封裝（flv/ts等）和流式協議打包（RTMP/HTTP等），然后直接將這些流式數據返回給客戶端。
下圖給出了用戶在請求流媒體數據的過程：
1）觀看者通過交互界面先請求web server;
2）webserver將這些RTMP等流式連接轉到流媒體服務器；
3）流媒體服務將對應的實時媒體數據通過RTMP等協議傳送給觀看者的Player。
下圖以RTSP流式協議為例給出了流媒體服務器最簡單的功能原理：
我們從圖中可以看出，RTMP/RTSP等實時流式協議都是基于TCP協議，所以流媒體服務器本質上來說就是個TCP服務器，跟所有的TCP服務器都有類似的邏輯結構。上圖中：RTP協議主要用來實際承載實時傳送的流媒體數據，包括音視頻數據，以及所攜帶負載的時間戳，順序號等。
RTCP主要完成接收者收到某個多媒體流的服務質量信息Qos，用于對服務器端的反饋。
RTSP（Real Time Streaming Protocol）是一種控制協議，完成對RTP中的流媒體數據進行各種狀態的控制。主要包括如播放、暫停、快進、錄制、結束播放等控制功能，也就是RTSP對多媒體服務器實施網絡遠程控制。
下圖以RTMP流式協議給出了流媒體服務器與Flash Player之間完整的交互過程：
通過以上6步，流媒體服務器就將媒體數據實時的源源不斷的傳送給Player，知道Player點擊停止按鈕為止。
以上就是流媒體服務器最基本的流式數據傳輸功能和原理，但事實上，一套實際直播平臺或者直播CDN分發系統中的流媒體服務器所承擔的功能遠比這個復雜。以觀止云BMS為例，下圖是BMS的架構圖，從圖中我們可以看出BMS在強大的輸入輸出支持以外，還有大量計費、監控、調度等涉及運營的BASIC接口，另外還有動態配置、實時截圖、安全特性、大數據等大量伴生進程和子系統。
（2）主流流媒體服務器對比一覽
目前市面上商用和開源的流媒體服務器比較多，此處只給出比較常用和主流的流媒體服務器列表，表格后面的維基百科鏈接中有20多款產品的全方位總結。
常用的商用流媒體服務器：
常用的開源流媒體服務器：
流媒體服務器對比一覽，涵蓋了基本信息、操作平臺、協議、格式等方面的詳細比較，Comparison of streaming media systems ：https://en.wikipedia.org/wiki/Comparison_of_streaming_media_systems
（3）衡量一款流媒體服務器的指標
由于當下流媒體應用尤其互聯網直播要求極高，如何從數十款流媒體服務器中選擇出適合自身流媒體平臺，或者自主研發需要注意哪些點。小編認為一款優秀的流媒體服務器需要具備：
功能支持：包括支持的協議、封裝格式、直播/點播/延播/截圖等應用功能等，倒不是說功能越多越好，每款服務器有自身定位，我們需要的是在特定場景下功能表現的優秀；
性能支持：主要看承載能力和穩定性，針對目前直播量級越來越大，單機承載量當然是越大越好。上述眾多的流媒體服務器中，就單進程來說大致的性能表現是BMS > SRS > Nginx-rtmp > Crtmpd > Wowza > fms > RED5；
配置運維：尤其是網絡直播是經常出問題的應用，流媒體服務器對運維工作的友好型也是大型直播平臺或CDN中非常重要的。比如節點擴容，程序更新，日常業務配置等等。服務器配置方式越簡單，運維越輕松越不容易出錯；
服務器日志：日志是定位故障分析問題的唯一途徑，所以優秀的、運營級的流媒體服務器需要日志的可讀性和友好性。
觀止云以往文章中詳細分析了主流流媒體服務器之間在協議支持、體系架構、核心功能支持、配置運維、性能、服務器日志、大數據這七大維度的橫向對比。
2.3 CDN分發網絡
CDN(Content Delivery Network)，即內容分發網絡。簡單來說CDN網絡是在各地建設邊緣節點，將源站的內容分發到距離用戶最近的網絡邊緣節點上，使得用戶可以就近獲取所需內容，以此來解決 Internet用網高峰期擁擠的狀況和跨網絡運營商響應慢的問題，整體上提升了用戶訪問網站的響應速度。典型的CDN架構如下：
CDN最初是建立在文件（圖文、文件）靜態內容的基礎上的，所以其核心的技術點在于WEB Cache緩存技術、集群技術、負載均衡/DNS調度等技術。隨著互聯網的發展，CDN后來出現了動態內容加速、流媒體加速、應用協議加速等類型，還補充了安全、數據分析等等增值服務，最新的動向可能是白山云提出的API加速了。
流媒體CDN加速網絡，點播應用中，國內大部分視頻網站均走文件分發方式，依然跑在Nginx設備上面，所以我們可以說和流媒體關系還不那么大。直播分發系統中，最主要的區別是它需要靠專門的流媒體服務器來分發，而且流媒體服務器的能力直接影響了CDN加速效果，另外，直播CDN一般不Cache內容，也無法預加載內容。但是，直播CDN的組網和調度基本思路還是大同小異，用戶訪問的流程也基本相同：
1）主播推送流媒體數據到流媒體服務器（源站） ，目前的直播應用一般還有上行加速過程，即主播先推送到最近的節點，節點再轉推到源站；
2）源站進行流媒體數據的分發；
3）觀眾點開播放器播放某直播流，經過域名解析后向CDN請求流媒體數據；
4）CDN經過調度將該請求分配給離該觀眾最近的邊緣節點，若節點上沒有該直播流存在，則節點向源站繼續請求流媒體數據；若節點上已有了該直播流，則直接響應流數據；
5）源站響應節點的請求，將流數據分發給該邊緣節點；
6）邊緣節點將流媒體數據傳送給該觀眾的播放器。
2.4 網絡協議
網絡協議指的是為了讓互聯網中客戶端與服務端之間，客戶端與客戶端之間進行數據交換而建立的一系列規則、標準等的集合，我們天天上網打交道的就是TCP/IP協議了，它是當下Internet上的“通用語言”，就好比我們中國人交流的普通話一樣。
流媒體是在互聯網上傳輸的特殊數據，需要有特定的規則和標準和承載，這就是我們要著重說的流媒體網絡協議，形式上，它好比是暗號，雖然也是用普通話表述，但不是提前知道暗號的人，就不會明白它在說什么。
流媒體協議也是流媒體系統中非常重要的組成部分，后續文章會對主要的流媒體協議進行一一詳述，此節僅進行流媒體協議的概述。
目前網絡直播應用的三大主要網絡協議是RTMP、HTTP-FLV、HLS，其它還有類似HLS的HDS/DASH、監控領域的RTSP，目前比較活躍的WebRTC、以及很多基于UDP的平臺內的私有協議。WebRTC和UDP私有協議第三方CDN都不容易支持，所以不作過多討論。
上述協議中，每個協議都有其自身特點和針對性，我們需要視自身業務特點進行選取。總結起來，對協議可以進行如下選擇：
編碼工具最好都輸出RTMP
流媒體服務器接入使用RTMP
流媒體系統內部全部使用RTMP
PC+直播+實時性要求高：使用RTMP，播放器使用Flash
PC+點播：使用HTTP文件分發或者HLS
IOS/ Andorid+直播+實時性要求高：都使用HTTP-FLV，播放器自己搞定
IOS/ Andorid+直播+實時性要求低：都使用HLS
和流媒體協議相關的還有一個概念是媒體封裝格式，就是我們天天所說的FLV/MP4/AVI/3GP等等音視頻文件格式，一般后綴在文件名尾部，RTMP這些流協議打包的數據就是已經封裝成FLV/TS這樣的封裝數據。以下維基百科詞條給出了數十種封裝格式的詳細對比，各自的音視頻編碼參數等等。
Comparison of video container formats：https://en.wikipedia.org/wiki/Comparison_of_video_container_formats
2.5 播放器
流媒體播放器實現的功能和流程與之前講的編碼工具剛好相反，歷經解協議，解封裝，解碼視音頻，視音頻同步幾個主干環節。
上述每一個步驟的具體作用跟編碼端是一樣的，不再贅述。在播放端中，PC端用Flash就足夠了，移動端可以基于ijkplayer這樣的開源跨平臺播放器去開發，關鍵點在于對移動端不同型號、網絡切換、播放中來電話、應用轉入后臺運行等等事件下進行針對性處理以及CPU解碼和GPU解碼之間的平衡。另外，首屏加載時間和延遲優化在播放端也大有文章可做，比如通過緩存最近一個GOP減少播放器數據下載量快速啟動解碼以提升首屏時間，合理的緩沖策略、追幀播放等來提升延時等。
除了盡可能優化播放體驗之外，由于播放端直接面向用戶，所以運營方面所可能涉及到的如廣告投放、觀看行為搜集等，都需要在播放端考慮。
針對HLS協議，video.js 和hls.js是兩個基于JavaScript的開源庫，能在HTML5 中播放HLS，Safari、IE11以上、Firefox、chrome等支持H5的瀏覽器均可直接調用video.js實現HLS的播放。
flv.js 是一款由B站開源的，原生JavaScript開發的，能在HTML5 中直接播放FLV格式的h.264/aac流媒體，兼容Safari、IE11以上、Firefox、chrome等。
以下維基百科詞條給出了幾十種播放器（商用的、開源的），數十項功能與性能的詳細對比：
Comparison of video player software：
https://en.wikipedia.org/wiki/Comparison_of_video_player_software
更多精彩內容，持續推送中，敬請關注！
本篇內容由觀止云原創，未經許可，禁止轉載。
更多干貨，盡在“觀止云”微信訂閱號（微信號bravovcloud）
我們將了解以下流協議，以便:
RTMP 流媒體協議是 Macromedia 開發的一種基于 TCP 的技術，用于在 Flash 播放器和服務器之間通過互聯網進行音頻、視頻和數據的流媒體傳輸。Macromedia 于2005年12月3日被競爭對手 Adobe 收購，但隨著 Flash 在2020年逐步淘汰，它的使用越來越少地與面向觀眾的內容交付有關，而更多地是通過支持 RTMP 的編碼器將實時流攝入到平臺中。
RTSP 建立并控制單個或多個時間同步的連續媒體流，如音頻和視頻。RTSP 本身通常不提供連續的流，盡管可以將連續的媒體流與控制流交織在一起。換句話說，RTSP 充當多媒體服務器的“網絡遠程控制”。
由于大多數 IP 攝像頭仍然支持 RTSP，它仍然是監控和閉路電視系統中使用的標準。
WebRTC 代表 Web 實時通信，它是一個非常令人興奮的、強大的、具有高度破壞性的尖端技術和流協議。
它與 HTML5兼容，你可以使用它直接在瀏覽器和設備之間添加實時媒體通信。另外，你可以做到這一點，而不需要在瀏覽器中安裝任何必備的插件。它正逐漸得到所有主要的現代瀏覽器供應商的支持，包括 Safari、 Google Chrome、 Firefox、 Opera 和其他瀏覽器。
感謝 WebRTC 視頻流技術，您可以直接將實時視頻嵌入到基于瀏覽器的解決方案中，為您的受眾創建一個迷人的互動流體驗，而不用擔心延遲。
HLS 是一種基于 HTTP 的自適應協議，用于將視頻和音頻數據/內容從媒體服務器傳輸到終端用戶的設備。
合肥光源于2009年由蘋果公司創建。蘋果發布 HLS 的時間與傳奇設備 iPhone3差不多。早期的 iPhone3有直播播放問題，蘋果希望通過 HLS 解決這個問題。
SRT 是一種開源技術，用于在不可預測的公共網絡上進行可靠且低延遲的流媒體傳輸。它直接與 RTMP 和 RTSP 競爭，作為第一英里的解決方案，但仍被采用作為編碼器，解碼器和播放器添加支持。SRT 在2020年的一個互動用例被證明是第一個虛擬 NFL 草案ーー確保高質量的流媒體和在任何有互聯網連接的地方的操作靈活性。
CMAF 是一種簡化基于 HTTP 的流媒體交付的新格式。它是一個新興的標準，有助于降低成本和復雜性，并提供大約3-5秒的延遲流。CMAF 可用于 DASH 或 HLS。
由于 RTMP 的地位不斷下降，其他基于 HTTP (超文本傳輸協議)的自適性串流技術也應運而生。但是，不同的流標準需要不同的文件容器。例如，當 MPEG-DASH 使用。MP4集裝箱，HLS 流交付在。其格式。
因此，每個想要接觸更多觀眾的廣播公司都必須對同一個視頻文件進行兩次編碼和存儲，因為加密創建了完全不同的文件組。
這兩個版本的同一個視頻流應提前或立即進行。這兩個過程都需要額外的存儲和處理成本。
蘋果和微軟建議移動圖片專家組創建一個新的統一標準，稱為通用媒體應用格式(CMAF) ，以降低在線視頻傳輸的復雜性。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
