整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
開源精選》是我們分享Github、Gitee等開源社區中優質項目的欄目，包括技術、學習、實用與各種有趣的內容。本期推薦的是一個開源的HTML5流媒體播放器——PearPlayer.js。
PearPlayer是完全用JavaScript寫的開源HTML5流媒體播放框架，實現了融合HTTP（含HTTPS、HTTP2）和WebRTC的多協議、多源、低延遲、高帶寬利用率的無插件Web客戶端流媒體加速能力。基于H5的MSE（Media Source Extension）技術將來自多個源節點的Buffer分塊喂給播放器，再加上精心設計的算法可實現最優的調度策略及對各種異常情況的處理，PearPlayer由此能在保證用戶流暢視頻體驗的前提下最大化P2P率。
首先通過script標簽導入pear-player.min.js：
<script src="./dist/pear-player.min.js"></script>或者使用CDN：
<script src="https://cdn.jsdelivr.net/npm/pearplayer@latest"></script>假設用video標簽播放以下視頻，HTML如下：
<video id="pearvideo" src="https://qq.webrtc.win/tv/Pear-Demo-Yosemite_National_Park.mp4" controls>只需以下幾行代碼，即可將PearPlayer綁定到video標簽：
<script>
/**
* 第一個參數為video標簽的id或class
* opts是可選的參數配置
*/
if (PearPlayer.isMSESupported()) {
var player = new PearPlayer('#pearvideo', opts);
}
</script>至此，就已經添加播放器了，無需任何插件。
開源地址：https://gitee.com/PearInc/PearPlayer.js
著互聯網行業的火爆發展，云計算行業也緊跟勢頭，進行快速發展階段。作為互聯網巨頭的網易也抓住此次機遇，對外推出了視頻云服務。在此前，網易視頻云（http://vcloud.163.com）服務已經廣泛運用于網易內部產品，比如網易BOBO，網易蜂巢，網易公開課等。4月6日，網易新聞客戶端和糗事百科合作進行的直播也是通過網易視頻云接入并進行直播。目前，網易視頻云服務的點播與直播功能均已上線，視頻云也廣泛應用于遠程醫療，在線教育，秀場直播、企業協作、遠程監控等領域。在此，網易視頻云的技術專家也給大家分享一些大家都關注的視頻技術內容，后期也會陸續分享，感興趣的朋友們也可以多關注網易視頻云官方網站，后期會推出更多的內容分享。
多媒體數據文件
一個完整的多媒體文件是由音頻和視頻兩部分組成的，H264、Xvid等就是視頻編碼格式，MP3、AAC等就是音頻編碼格式，字幕文件只是附加文件。目前大部分的播放器產品對于H.264 + AAC的MP4編碼格式支持最好，但是MP4也有很多的缺點，比如視頻header很大，影響在線視頻網站的初次加載時間。
為了降低頭部體積，需要進行視頻本身的物理分段等等。對MPEG2-TS格式視頻文件進行物理切片，分成一小段，這種方式被Apple公司的HTTP Live Streaming (HLS)技術采用。另外一種是使用Fragmented MP4文件格式，這是一種文件內部的邏輯分割方式，而視頻文件還是完整的，這種技術被Microsoft Smooth Streaming和Adobe HTTP Dynamic Streaming采用。很多在線視頻網站在帶寬耗費的壓力下，主要選擇的是adobe公司提供的FLV或F4V， FLV是流媒體封裝格式，可將其數據看為二進制字節流。總體上看，FLV包括文件頭（File Header）和文件體（File Body）兩部分，其中文件體由一系列的Tag及Tag Size對組成。
流媒體傳輸類型
流媒體在播放前不是完全下載整個文件，而是把開始部分內容存入內存，數據流是隨時傳送隨時播放。
流媒體服務器提供的流式傳輸方式有兩種：順序流式傳輸和實時流式傳輸兩種方式。
順序流式傳輸是順序下載，在下載文件的同時用戶可觀看在線媒體。如果使用普通的HTTP服務器，將音視頻數據以從頭至尾方式發送，則為順序流媒體傳輸。實時流式傳輸總是實時傳送，特別適合現場事件。一般來說，如果視頻為現場直播，或使用專用的流媒體服務器，或應用如RTSP等專用實時協議，即為實時流媒體傳輸。實時流式傳輸必須匹配連接帶寬，這意味著圖像質量會因網絡速度降低而變差。
在流式傳輸時，流媒體數據具有實時性，等時性等基本特點，流服務期和客戶終端要保證各種媒體間的同步關系，因此，流媒體傳輸對“最大延時”，“延時抖動”等QoS參數都有嚴格要求。
實時流傳輸既可傳輸實況直播，也可傳輸完整的音視頻文件（專用協議流式）。
順序流媒體不可用于實況直播，僅能傳輸完整的音視頻文件（HTTP漸進式）。
| 區別 | 實時流 | 順序流 |
| 音視頻數據源 | 實時從錄制設備上采集，或（使用專用協議傳輸的）文件 | 可播放的音視頻文件 |
| 服務器類型 | 專用流媒體服務器，如：QuickTime Streaming ServerReal ServerWindows Media ServerFlash Media Server | 普通的HTTP服務器，或FTP服務器 |
| 傳輸協議 | 專用協議RTSP，HLS或RTMP等 | 一般的HTTP協議，與傳輸網頁的協議相同 |
| 跳播 | 可隨機訪問任意片段 | 在給定時刻，用戶只能觀看已下載的那部分，而不能跳到還未下載的部分 |
主流的流媒體協議
主流的流媒體協議主要有： RTMP， HLS， RTSP等。
| 區別 | RTMP | HLS | RTSP |
| 全稱 | Real Time Message Protocol | Http Live Stream | Real Time Streaming Protocol |
| 上層協議 | TCP或HTTP | HTTP | RTP，RTCP |
| 軟件模型 | C\S | B\S | C\S |
| 研發主要來自 | Adobe | Apple | Microsoft |
| 針對客戶端 | 支持Flash類產品的瀏覽器支持HTML5的瀏覽器 | 蘋果的Safari瀏覽器支持HTML5的瀏覽器 | 播放器 |
| 視頻格式要求 | FLV， F4V | MP4 | 無 |
| 服務器要求 | 專用Flash服務器Flash Media ServerRed5 | 普通HTTP服務器 | 專用RTSP流媒體服務器 |
| 實況直播要求 | 專用編碼器上傳Flash Media Encoder | 專用編碼器上傳Apple開發工具 | 與服務器相關，自定義上傳 |
| 文件播放要求 | FLV ，F4V文件即可，服務器會自動分解為F4f 數據文件f4x索引文件 | TS數據文件，M3u8索引文件 | 與服務器相關，與播放器相關 |
流媒體協議原理
(一)HTTP漸進式下載原理（僅支持文件播放）
HTTP邊下載邊播放，嚴格意義上講，不是直播協議。他的原理是先下載文件的基本信息，音頻視頻的時間戳，再下載音視頻數據，以播放mp4為例，先下載文件頭，根據文件頭指引下載文件尾，然后再下載文件的音視頻數據。
播放方式：瀏覽器調用系統播放器播放；
使HTML5的Video標簽，瀏覽器支持直接播放。
(二)蘋果支持的HLS原理（實況直播、文件點播）
服務器端有三個組件：
其一：編碼器（media encoder）, 用于將設備輸出的格式轉為H264和AAC，并封裝為MPEG-2傳輸流；
其二：流分段器（stream segmenter）, 用于實況直播，將MPEG-2流分割為多個小片段后輸出；
其三：文件分段器（file segmenter）, 用于文件點播，將文件分隔為多個小片段后輸出；
分發原理
數據經以上三部分處理后為.ts文件（媒體數據）及.m3u8文件（媒體數據索引）存在于服務器之上。 客戶端訪問.m3u8后按索引下載.ts文件進行播放。
下面為某m3u8文件內容：
#EXTM3U
#EXT-X-TARGETDURATION:30
#EXTINF:30,
http://192.169.1.176/sample_100k-1.ts
#EXTINF:30,
http://192.169.1.176/sample_100k-2.ts
#EXTINF:30,
http://192.169.1.176/sample_100k-3.ts
#EXT-X-ENDLIST
根據這個文件，播放器會依次下載sample_100k-1.ts，sample_100k-2.ts，sample_100k-3.ts
HLS的文件點播
1.使用蘋果開發工具“文件分段器”將基于H264和AAC或MP3的MPEG4分段，
生成.ts和.m3u8文件，存儲于普通服務器上。
2.蘋果應用程序或蘋果瀏覽器可以通過訪問.m3u8文件獲取到索引，并下載所需要的數據片段來播放。
HLS的實況直播
1.使用蘋果開發工具“流分段器”將基于H264、AAC、MP3的MPEG2傳輸流分段，
可使用其它工具將MPEG4音視頻文件加載到MPEG2傳輸流當中。
生成.ts和.m3u8文件，存儲于普通服務器上。
2.蘋果應用程序或蘋果瀏覽器可以通過訪問.m3u8文件獲取到索引，并下載所需要的數據片段來播放。
(三)Adobe Flash支持的RTMP協議（支持文件播放 和 實況直播）
RTMP(Real Time Messaging Protocol)
是Adobe Systems公司為Flash播放器和服務器之間音頻、視頻和數據傳輸 開發的開放協議。
它有四種變種：
1)工作在TCP之上的明文協議，使用端口1935；
2)RTMPS通過TLS/SSL連接；
3)RTMPT封裝在HTTP請求之中，可穿越防火墻；
4)RTMPS類似RTMPT，但使用的是HTTPS連接；
RTMP協議(Real Time Messaging Protocol)是被Flash用于對象,視頻,音頻的傳輸。這個協議建立在TCP協議或者輪詢HTTP協議之上。RTMP協議就像一個用來裝數據包的容器,這些數據既可以是AMF格式的數據,也可以是FLV中的視/音頻數據。一個單一的連接可以通過不同的通道傳輸多路網絡流，這些通道中的包都是按照固定大小的包傳輸的。
必須采用Flash服務器FMS(Flash Media Server) 或 RED5.
FMS的文件點播
1.服務器將F4v 或 Flv文件轉化為RTMP流或HTTP流
2.客戶端獲取RTMP流，提取相應的Flv 或 F4v文件片段進行播放。
FMS的實況直播
1.設備端將數據轉化為F4v片段，通過RTMP流上傳到服務器
2.服務器轉發RTMP流到客戶端
3.客戶端獲取RTMP流，提取數據片段播放。
(四)RTSP協議
該協議用于C/S模型，是一個基于文本的協議，用于在客戶端和服務器端建立和協商實時流會話。
實時流協議（RTSP）是應用級協議，控制實時數據的發送。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻的受控點播成為可能。數據源包括現場數據與存儲在剪輯中數據。該協議目的在于控制多個數據發送連接，為選擇發送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP上發送機制提供方法。
實時流協議（RTSP）建立并控制一個或幾個時間同步的連續流媒體。盡管連續媒體流與控制流交換是可能的，通常它本身并不發送連續流。換言之，RTSP充當多媒體服務器的網絡遠程控制。RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用戶可打開或關閉多個對服務器的可傳輸連接以發出RTSP請求。此外，可使用無連接傳輸協議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續媒體的傳輸機制。
協議支持的操作如下：
(1）從媒體服務器上檢索媒體：用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用于連續媒體的的組播地址和端口。如演示僅通過單播發送給用戶，用戶為了安全應提供目的地址。
(2）媒體服務器邀請進入會議：媒體服務器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分布式教育應用上很有用，會議中幾方可輪流按遠程控制按鈕。
(3）將媒體加到現成講座中：如服務器告訴用戶可獲得附加媒體內容，對現場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。
下面區分幾種操作模式。
(1）單播：用戶選擇的端口號將媒體發送到RTSP請求源。
(2）服務器選擇地址多播：媒體服務器選擇多播地址和端口，這是現場直播或準點播常用的方式。
(3）用戶選擇地址多播：如服務器加入正在進行的多播會議，多播地址、端口和密鑰由會議描述給出。
RTSP控制通過單獨協議發送的數據流，與控制通道無關。例如，RTSP控制可通過TCP連接，而數據流通過UDP。因此，即使媒體服務器沒有收到請求，數據也會繼續發送。在連接生命期，單個媒體流可通過不同TCP連接順序發出請求來控制。所以，服務器需要維持能聯系流與RTSP請求的連接狀態。RTSP中很多方法與狀態無關，但下列方法在定義服務器流資源的分配與應用上起著重要的作用：
(1) SETUP：讓服務器給流分配資源，啟動RTSP連接。
(2) PLAY與RECORD：啟動SETUP分配流的數據傳輸。
(3) PAUSE：臨時停止流，而不釋放服務器資源。
(4) TEARDOWN：釋放流的資源，RTSP連接停止。
標識狀態的RTSP方法使用連接頭段識別RTSP連接，為響應SETUP請求，服務器連接產生連接標識。
RTSP為純粹的傳輸控制協議。
RTSP協議本身不與它負載的媒體數據相關。
RTSP協議需要自定義客戶端向服務器發送RTSP命令。
流媒體服務器的協議棧
在TCP／IP參考模型中，傳輸層通信協議TCP和UDP都不能滿足流媒體傳輸的QoS要求。由于TCP協議采用滑動窗口控制機制，數據傳送隨著流控窗口動態的啟動和關閉，難以滿足流媒體實時和等時的傳送要求。UDP協議的無連接特點能夠提高傳輸速率，雖然可以在某種程度上滿足流媒體的實時性要求，但是由于其本身的不可靠性，也無法滿足流媒體傳輸的需要。
針對傳輸層協議的矛盾，為了實現流媒體在IP上的實時傳送播放，設計流媒體服務器時需要在傳輸層協議（TCP／UDP）和應用層之間增加一個通信控制層。在增加的通信控制層，采用相應的實時傳輸協議，主要有：數據流部分的實時傳輸協議RTP（Real－time Transport Protocol），用于控制部分的實時傳輸控制協議RTCP（Real－time Control Protocol）和實時流化協議RTSP（Real－time Streaming Protocol）。
流媒體服務器的協議棧，如圖1所示。
RTP協議主要是用來傳送實時的流媒體信息，數據報主要包括多媒體數據，以及所攜帶負載的時間戳，順序號等。
RTCP協議的數據報主要包括了接收者收到某個多媒體流的服務質量信息Qos，用于對服務器端的反饋。
RTSP是一種控制協議，包括通信連接前的設定，從服務器送出的多媒體資料的控制。用于控制具有實時性的數據傳輸。它提供對流媒體的類似VCR（Video Cassette Recorder）的控制功能，如播放、暫停、快進、錄制等，也就是RTSP對多媒體服務器實施網絡遠程控制。
流媒體服務器的功能框圖，如圖2所示。
當服務器收到RTSP請求，它首先產生RTSP請求對象。服務器通過RTSP協議的應答信息將請求的內容以流會話（streaming session）的形式描述，內容包括數據流包含多少個流、媒體類型、和編解碼格式。一個流會話由一個或多個數據流組成，如視頻流和音頻流等。實際的數據流通過RTP協議傳遞到客戶端。RTP在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現流同步。RTP本身并不能為順序傳送數據包提供可靠的傳送機制，它依靠RTCP一起提供流量控制和擁塞控制服務。在RTP會話期間，各連接者監視下層網絡的性能，并將相關信息放入RTCP包，周期性地傳送RTCP包來通知發送方。發送方也可以用RTCP包提供每次的會話信息，包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料。因此，服務器可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，因有效的反饋和最小的開銷使傳輸效率最佳化。
通過流媒體服務器的協議棧的設計，可以明確流媒體服務器是在傳輸層協議（TCP，UDP）上解釋RTP，RTCP，RTSP協議的，所有的客戶連接請求都是以TCP的端口獲得的，流媒體數據也都是打成RTP包，通過UDP端口發出去的，因此，對于TCP，UDP端口事件的調度以及如何把大量的流媒體數據從磁盤空間傳遞到網絡上成為制約流媒體服務器性能的主要因素。
傳統流媒體服務器的處理流程，如圖3所示。
流媒體服務器面對一個單一的客戶，完成的過程如下：
1）在客戶端發出RTSP連接請求后，服務器通過對TCP端口的監聽，讀入請求。
2）解析請求內容，調入相應的流媒體文件。
3）形成RTP包，分發數據流包，獲得RTCP包。
4）數據包發送完畢，關閉連接。
上圖是RTSP直播服務器的系統框圖。
從攝像頭采集實時圖像，送到編碼器進行實時編碼，一般是生成TS格式的數據流，然后數據流輸出到視頻直播服務器。客戶端先發送請求到web服務器，然后再重定向到RTSP視頻服務器，從視頻服務器讀取數據，同時實現播放，暫停等功能。
流媒體的傳輸技術
一、單播：
主機之間“一對一”的通訊模式，網絡中的交換機和路由器對數據只進行轉發不進行復制。如果10個客戶機需要相同的數據，則服務器需要逐一傳送，重復10次相同的工作。但由于其能夠針對每個客戶的及時響應，所以現在的網頁瀏覽全部都是采用IP單播協議。網絡中的路由器和交換機根據其目標地址選擇傳輸路徑，將IP單播數據傳送到其指定的目的地。
單播的優點：
1. 服務器及時響應客戶機的請求
2. 服務器針對每個客戶不通的請求發送不通的數據，容易實現個性化服務。
單播的缺點：
1. 服務器針對每個客戶機發送數據流，服務器流量＝客戶機數量×客戶機流量；在客戶數量大、每個客戶機流量大的流媒體應用中服務器不堪重負。
二、 廣播：
主機之間“一對所有”的通訊模式，網絡對其中每一臺主機發出的信號都進行無條件復制并轉發，所有主機都可以接收到所有信息（不管你是否需要），由于其不用路徑選擇，所以其網絡成本可以很低廉。在數據網絡中也允許廣播的存在，但其被限制在二層交換機的局域網范圍內，禁止廣播數據穿過路由器，防止廣播數據影響大面積的主機。
廣播的優點：
1. 網絡設備簡單，維護簡單，布網成本低廉
2. 由于服務器不用向每個客戶機單獨發送數據，所以服務器流量負載極低。
廣播的缺點：
1.無法針對每個客戶的要求和時間及時提供個性化服務。
2. 網絡允許服務器提供數據的帶寬有限，客戶端的最大帶寬＝服務總帶寬。
3. 廣播禁止在Internet寬帶網上傳輸。
三、組播：
主機之間“一對一組”的通訊模式，也就是加入了同一個組的主機可以接受到此組內的所有數據，網絡中的交換機和路由器只向有需求者復制并轉發其所需數據。主機可以向路由器請求加入或退出某個組，網絡中的路由器和交換機有選擇的復制并傳輸數據，即只將組內數據傳輸給那些加入組的主機。這樣既能一次將數據傳輸給多個有需要（加入組）的主機，又能保證不影響其他不需要（未加入組）的主機的其他通訊。
組播的優點：
1. 需要相同數據流的客戶端加入相同的組共享一條數據流，節省了服務器的負載。具備廣播所具備的優點。
2. 由于組播協議是根據接受者的需要對數據流進行復制轉發，所以服務端的服務總帶寬不受客戶接入端帶寬的限制。
3. 此協議和單播協議一樣允許在Internet寬帶網上傳輸。
組播的缺點：
1．與單播協議相比沒有糾錯機制，發生丟包錯包后難以彌補，但可以通過一定的容錯機制和QOS加以彌補。
2．現行網絡雖然都支持組播的傳輸，但在客戶認證、QOS等方面還需要完善，這些缺點在理論上都有成熟的解決方案，只是需要逐步推廣應用到現存網絡當中。
自適性串流技術
自適性串流（ABS - adaptive bitrate streaming），是一種在電腦網絡使用的一種串流技術。過去的流媒體技術多使用 RTP/RTSP，但現在的技術則大多基于 HTTP，并為更高效在大型分布式HTTP網絡（例如互聯網）分發而設計。
此技術根據實時檢測的用戶的帶寬和CPU使用率，調整視頻流的質量。這需要使用一種可以將單一視頻源輸出為多碼率的編碼器。播放器客戶端依賴可用資源在不同碼率的流之間切換。"結果就是：更少緩存、更快的開始播放、為低端和高端鏈接都提供良好的體驗。
根據當前廣泛使用的實現，更具體來說，自適應串流（ABS）：
使用 HTTP 傳送視頻流；
使用多碼率編碼源內容；
每個單碼率的流被切成小的，幾秒鐘的小切片；
流媒體客戶端首先獲取所有碼率的切片索引信息。一開始，客戶端先請求最低碼率的串流。如果客戶端判斷下載速度比當前碼率的切片串流快，它就去請求下一個更高碼率的串流。隨著播放的進行，如果客戶端發現下載速度比當前碼率的切片串流慢，轉而請求下一個較低碼率的串流。
切片大小和具體實現密切相關，不過一般都在2～10秒之間。每個切片由一個完整的GOP序列組成，一個GOP序列里面有1個或者多個I幀，GOP序列的第一個幀必須是I幀，并且每個切片都能單獨的解碼播放顯示。
與傳統的流媒體技術比較，缺點：需要額外的存儲，更多的編碼代價，復雜的只適應碼率邏輯。
Adaptive streaming overview
Adaptive streaming in action
MPEG-DASH (Dynamic Adaptive Streaming over HTTP)
MPEG-DASH 是基于HTTP的自適應串流方案中的唯一國際標準。MPEG-DASH 技術由 MPEG 主導開發：
2010年開始DASH相關工作，2011年1月成為國際標準草案，2011年11月成為國際標準[3]，2012年4月，MPEG-DASH 以ISO/IEC 23009-1:2012 發表。
MPEG-DASH 基于3GPP第9版的 Adptive HTTP streaming（AHS）和 Open IPTV Forum第2版的 HTTP Adaptive Streaming (HAS)。作為與MPEG合作的一部分，3GPP第10版采用了DASH（采用特別的編碼和操作模式），用于無線網絡。
可用的 MPEG-DASH 實現有：
bitmovin GmbH 的開源 DASH 客戶端庫 libdash 和 DASHEncoder
Adobe HDS (HTTP Dynamic Streaming)
Flash Player 和 Flash Media Server 的最新版支持傳統的 RTMP 協議和 HTTP協議。后者和Apple和微軟基于HTTP的方案類似。
基于HTTP的流的優勢是：
不需要防火墻開普通web瀏覽器所需端口以外的任何端口
允許視頻切片在瀏覽器、網關和CDN的緩存，從而顯著降低源服務器的負載。
HDS 的文件格式為 FLV/F4V/MP4，索引文件為 f4m，同時支持直播和時移。
Apple HLS (HTTP Live Streaming)
是一種基于HTTP的媒體流通信協議，在 iPhone 3.0 及更新版中成為標準功能。
2010年10月，所有自適應串流方案都作為產權提供時，Apple 將HLS提交到 IETF，成為正式的 RFC.
HLS 串流使用擴展名為 .m3u8 的文件作為索引，文件切片格式為TS，支持直播和時移。支持的客戶端包括 iPad, iPhone, STB，VLC和其他支持的設備。
Microsoft MSS (Microsoft Smooth Streaming)
Smooth Streaming 是IIS的媒體服務擴展，用于支持基于HTTP的自適應串流。
在2010年11月發布的 IIS Media Services 4.0 中，微軟引入了一項使 Live Smooth Streaming H.264/AAC 視頻動態封裝成 Apple HLS 格式的功能，直接提供給 iOS 設備，而不需要再次編碼。同時支持直播和點播把1080P全高清視頻發送到Silverlight客戶端。
MSS 的文件切片格式為 mp4（fragmented-mp4），索引文件為ism/ismc，同時支持直播和時移。
流行視頻網站的流媒體服務器架構
為了能夠提供各類設備的在線視頻播放需求，對于在線視頻流媒體服務，提出了很多需求，對于早期建立的視頻網站（土豆，優酷，ku6等）都只提供一種視頻流媒體格式（FLV）的支持，我們稱之為單一的流媒體服務架構，如圖：
圖1 ：單一流媒體服務的架構圖
但是，在實際業務運營中遇到了很多問題：
1） 視頻存儲的壓力很大
同一種視頻碼流（h.264）,因為針對不同平臺應用設備（如表2）的播放需求，需要不同的封裝格式，需要將產生大量重復視頻流存儲的壓力，視頻網站的視頻量巨大，多支持一種格式將產生幾百TB級的存儲壓力，從機房到機柜，視頻流同步等環節負載和壓力都是巨大的。
2） 封裝后的視頻格式是否真的被播放
視頻流封裝完成后，同步到各地的中心節點后，是否真的有視頻流請求產生，還是僅僅處于視頻準備狀態，是否會影響中心節點的磁盤占用，緩存節點的命中率不高。
3） 封裝格式的功能性升級，導致老視頻再次封裝
封裝格式的不斷發展，TS流，HTTP live Stream的不斷優化，將導致現有的視頻流不斷需要翻新或重復封裝。 為了解決上述各類問題，視頻網站流媒體服務的研發工程師進行了多格式的流媒體服務架構探索，提供了各類視頻封裝格式的流媒體封裝反向代理接口，該接口能夠通過URL的請求，完成對特定視頻編碼格式（h.264）的封裝。
圖2：多格式的流媒體服務架構：
如圖所示，“流媒體容器封裝服務“成為多格式視頻流服務的核心，對于這個流媒體的封裝服務，通過對h.264的視頻編碼流進行不同格式的封裝，提供了多種視頻流的推送。對于這個服務，我們希望能夠盡快為視頻的cache服務推送視頻流，所以，在硬盤方面，選擇了每分鐘15000轉的SAS硬盤，降低同一視頻流的不同封裝請求的IO延遲等待。
作為最簡單和原始的流媒體解決方案，單一流媒體服務架構唯一顯著的優點在于它僅需要維護一個標準的視頻流文件，而這樣的服務器基礎設施在互聯網中已經普遍存在，其安裝和維護的工作量和復雜性比起多格式流媒體服務架構來說要簡單和容易的多。然而其缺點和不足卻也很多，首先是維護的工作量較大，多份相同視頻文件由于封裝格式不相同，需要同時維護多個實體的碼流文件，大量的占用磁盤的空間，再次，轉碼集群需要針對多種不同的封裝格式，進行多次的視頻轉碼，搶占很多資源，缺乏靈活的控制功能和擴展機制。
流媒體（streaming media）是指將一連串的媒體數據壓縮后，經過網上分段發送數據，在網上即時傳輸影音以供觀賞的一種技術與過程，此技術使得數據包得以像流水一樣發送；如果不使用此技術，就必須在使用前下載整個媒體文件。流媒體實際指的是一種新的媒體傳送方式，有聲音流、視頻流、文本流、圖像流、動畫流等，而非一種新的媒體。主要相關協議包含：RTSP、RTMP、HLS、HTTP-FLV、WebSocket-FLV、HTTP-TS、WebSocket-TS、HTTP-fMP4、WebSocket-fMP4、MP4、WebRTC等。下面我們對其中幾種協議進行介紹。
RTSP(Real Time Streaming Protocol):實時流媒體協議，是TCP/IP協議體系中的一個在IP網絡上傳輸流媒體數據的應用層協議，RTSP提供一種可擴展的框架，使能夠提供能控制的，按需傳輸實時數據，如音頻流、視頻流。RTSP在體系結構上位于RTP和RTCP之上，它使用TCP或UDP完成數據傳輸。HTTP與RTSP相比，HTTP請求由客戶機發出，服務器作出響應；使用RTSP時，客戶機和服務器都可以發出請求，即RTSP可以是雙向的。RTSP是用來控制聲音或影像的多媒體串流協議，并允許同時多個串流需求控制，傳輸時所用的網絡通訊協定并不在其定義的范圍內，服務器端可以自行選擇使用TCP或UDP來傳送串流內容，它的語法和運作跟HTTP 1.1類似，但并不特別強調時間同步，所以比較能容忍網絡延遲。
協議分層
通信流程
通信流程
RTMP(Real Time Messaging Protocol)實時消息傳輸協議是Adobe公司提出得一種媒體流傳輸協議，其提供了一個雙向得通道消息服務，意圖在通信端之間傳遞帶有時間信息得視頻、音頻和數據消息流，其通過對不同類型得消息分配不同得優先級，進而在網傳能力限制下確定各種消息得傳輸次序。
RTMP是TCP/IP協議模型中的應用層協議，其工作在TCP之上，默認端口為1935，RTMP協議是基于TCP協議進行傳輸，因此其需要TCP特性來保證消息傳輸的可靠性，TCP通過三次握手成功建立連接后，RTMP協議還需要客戶端和服務端通過RTMP握手協議來建立RTMP Connection,RTMP握手協議主要目的是協商RTMP版本及時間對齊作用。
RTMP Connection上會傳輸RTMP控制信息，比SetChunkSize,SetACKWindowSize，CreateStream等，其中CreateStream命令會創建一個Stream鏈接，用于傳輸具體的音視頻數據和控制這些信息傳輸的命令信息。RTMP協議以RTMP Message格式傳輸，為了更好地實現多路復用、分包和信息的公平性，發送端把Message劃分為帶有MessageID的Chunk，每個Chunk可能是一個單獨的Message，也可能是Message的一部分，在接受端會根據chunk中包含的data的長度，messageid和message的長度把chunk還原成完整的Message，從而實現信息的收發。
RTMP通信流程
HLS（HTTP Live streaming），是基于HTTP的流媒體傳輸協議，由Apple公司所提出的一種用于傳輸音視頻的協議交互方式，當前HLS被廣泛應用于視頻點直播領域。HLS采用HTTP協議傳輸音視頻數據，HLS通過將音視頻流切割成一個個小的TS切片及生成m3u8的播放列表文件，播放客戶端通過HTTP協議下載播放列表文件，按照播放列表文件制定的順序下載切片文件并播放，從而實現邊下載邊播放，類似于實時在線播放的效果。
由于傳輸層只采用HTTP協議，因此其具備HTTP的網傳優勢，比如可以方便的透過防火墻或者代理服務器，可簡單的實現媒體流的負載均衡，可以方便的結合CDN進行媒體分發等，另外HLS協議本身可實現碼率自適應，通過視頻轉碼，切片成不同碼率的TS文件（碼流），從而實現播放客戶端根據網絡帶寬情況，自由的選擇碼流進行播放，但是HLS在直播時延時較大。 采用HLS協議傳輸流媒體的優劣勢總結如下：
l 優勢：客戶端支持簡單，H5 video即可直接播放；網絡兼容性好，可很方便的通過防火墻或代理服務器，可很簡單的實現媒體流的負載均衡，CDN支持良好；自帶多碼率自適應機制，實現播放碼率自由選擇。
l 劣勢：延時較高，不能用于對延時較為苛刻的場景，如互動直播領域；TS切片較多，特別是實時視頻流，需要動態的生成和刪除TS切片文件，為了實現高性能、低碎片化，對于文件存儲的邏輯需要更加復雜的設計。
HLS整體流程框圖如下：
HLS流程圖
音視頻輸入單元采集音視頻數據，通過媒體編碼器編碼成所需要的編碼格式和碼率，并以TS格式對音視頻流進行封裝，流切片器對封裝好的TS流，按照預設的分割時間大小對TS流進行切片，并同時更具切片信息生成或更新m3u8文件列表文件，把播放列表文件和TS文件存儲到web服務器配置的路徑下，播放客戶端通過HTTP協議向web服務器拉取播放列表，根據播放列表內容依次拉取TS切片文件并播放。
l 媒體編碼器(media decoder)：媒體編碼器獲取音視頻設備的實時信號，通過預設的編碼格式進行編碼，或者通過流媒體協議接入已編碼好的音視頻流，根據流媒體預設條件確定是否需要轉碼，由編碼或者轉碼操作，得到編碼后的音視頻流，然后根據TS封裝格式對音視頻流進行封裝，封裝后發送到切片器進行切片。
l 流切片器(stream segmenter)：接收媒體編碼器打包好的TS流，或者讀取TS流的錄像文件，按照預設時間間隔把TS流切片成等時間間隔的TS流切片文件，并生成或更新索引文件(m3u8文件/playlist播放列表文件)，每個新的切片生成之后，索引文件都要更新，索引文件用于定位切片文件的位置及有效性判斷。
l web服務器：用來提供HTTP服務器，并提供索引文件和切片文件下載的服務，這里可采用nginx來搭建。
HTTP-FLV，即將音視頻數據封裝成 FLV，然后通過 HTTP 協議傳輸給客戶端。FLV (Flash Video) 是 Adobe 公司推出的另一種視頻格式，是一種在網絡上傳輸的流媒體數據存儲容器格式。其格式相對簡單輕量，不需要很大的媒體頭部信息。整個FLV由 The FLV Header, The FLV Body 以及其它 Tag 組成。因此加載速度極快。采用 FLV 格式封裝的文件后綴為 .flv。而HTTP-FLV 即將流媒體數據封裝成 FLV 格式，然后通過 HTTP 協議傳輸給客戶端。
HTTP協議中有個約定：Content-Length字段，HTTP的body部分的長度服務器回復HTTP請求的時候如果有這個字段，客戶端就接收這個長度的數據然后就認為數據傳輸完成了，如果服務器回復HTTP請求中沒有這個字段，客戶端就一直接收數據，直到服務器跟客戶端的socket連接斷開。
HTTP-FLV直播就是利用第二個原理，服務器回復客戶端請求的時候不加Content-Length字段，在回復了HTTP內容之后，緊接著發送flv數據，客戶端就一直接收數據了。
FLV數據包
（1）優點
HTTP-FLV 依靠 MIME 的特性，根據協議中的 Content-Type 來選擇相應的程序去處理相應的內容，使得流媒體可以通過 HTTP 傳輸。相較于 RTMP 協議，HTTP-FLV 能夠較好的穿透防火墻，它是基于 HTTP/80 傳輸，有效避免被防火墻攔截。除此之外，它可以通過 HTTP 302 跳轉靈活調度/負載均衡，支持使用 HTTPS 加密傳輸，也能夠兼容支持 Android，iOS 的移動端。
（2）缺點
由于HTTP-FLV的傳輸特性，會讓流媒體資源緩存在本地客戶端，在保密性方面不夠好。因為網絡流量較大，它也不適合做拉流協議。
基于WebSocket傳輸FLV，依賴瀏覽器支持播放FLV。WebSocket建立在HTTP之上，建立WebSocket連接前還要先建立HTTP連接。基于WebSocket來傳輸FLV格式的音視頻。可以用來替代RTMP，解決其需要瀏覽器端依賴flash的問題；替代HTTP-FLV，解決瀏覽器同域名請求的最大并發數限制導致的瀏覽器只能播放6路HTTP-FLV流的問題。
fMP4
FMP4格式（Fragmented MP4）是一種視頻和音頻流媒體格式，是MPEG-4 Part 12標準的一種擴展。與傳統的MP4格式不同，FMP4格式將媒體文件分成若干個片段（Fragment），每個片段都是一個完整的MP4文件，其中包含了媒體數據、元數據和索引信息。
FMP4格式（Fragmented MP4）是一種視頻和音頻流媒體格式，是MPEG-4 Part 12標準的一種擴展。與傳統的MP4格式不同，FMP4格式將媒體文件分成若干個片段（Fragment），每個片段都是一個完整的MP4文件，其中包含了媒體數據、元數據和索引信息。
FMP4格式的應用范圍廣泛，包括直播、點播、視頻會議等。它具有低延遲、高清晰度、高效傳輸等特點，能夠為用戶帶來更加流暢和穩定的視聽體驗。
HTTP-fMP4 (HTTP-Fragmented MP4)是一種使用HTTP協議傳輸fMP4格式的流媒體的協議。fMP4是一種流式媒體格式，通常與HTML5視頻播放器一起使用。它支持更好的流式傳輸和更好的性能，適用于現代Web應用和移動設備。
WebSocket-fMP4（Fragmented MP4） 是一種使用WebSocket協議傳輸fMP4格式的流媒體的協議。它具有實時性，與HTML5視頻播放器兼容，適用于現代Web應用和移動設備。總的來說，HTTP-FLV 和 WebSocket-FLV 使用了FLV格式，而HTTP-fMP4 和 WebSocket-fMP4 使用了fMP4格式。FLV通常與Flash相關，而fMP4更適合現代Web和移動設備。WebSocket-FLV 和 WebSocket-fMP4 都使用WebSocket協議，適用于實時流傳輸。選擇其中一個協議取決于您的需求和項目的技術棧。
WebRTC（Web Real-Time Communication），是一個支持網頁瀏覽器進行實時語音對話或視頻對話的API。WebRTC使用安全實時傳輸協議（Secure Real-time Transport Protocol，SRTP）對RTP數據進行加密，消息認證和完整性以及重播攻擊保護。它是一個安全框架，通過加密RTP負載和支持原始認證來提供機密性。WebRTC的安全特性是其可靠性的重要組成部分，其基礎全部圍繞實時傳輸協議（Real-time Transport Protocol）進行。
WebRTC目前比較普遍的框架描述如下圖所示，WebRTC整體架構從上到下一共分為三層，最上層是WebAPI層，這一層是暴露給開發人員的用于開發WebRTC應用的JavaScript API;中間的那一層是WebRTC技術最為關鍵核心的一層，一共包括三個模塊，分別是音頻引擎、視頻引擎以及網絡傳輸；最下層是由各廠商自主開發的一層，用于實現音視頻的采集和網絡IO。
WebRTC整體架構
l 音頻引擎
音頻引擎（VoiceEngine）負責WebRTC的音頻通信，通過一套完整的音頻處理框架，解決了音頻從外接設備如麥克風讀入數據然后再通過網絡進行傳輸的音頻處理問題。主要分為兩個模塊：音頻編解碼和語音信號處理。其核心是回聲消除(AcousticEchoCancceler，AEC)和降噪(NoiseReduction，NR)。回聲消除是一種改善聲音質量，消除產生的回聲或防止其發生的方法。降噪是從信號中去除噪聲的過程。音頻機制主要分為iSAC和iLBC兩大類編解碼器。iLBC編解碼器該窄帶音頻編解碼器適用于IP上的語音通信。
l 視頻引擎
視頻引擎（VideoEngine）負責WebRTC的視頻通信，通過一套完整的視頻處理框架，解決了視頻從外接設備如攝像頭采集數據然后再通過網絡傳輸最后顯示視頻的視頻處理問題。主要分為兩個模塊：視頻圖像編解碼和視頻圖像處理。視頻圖像編解碼方面，默認的編解碼器是VP8，比較適合實時通信場景下的視頻編解碼。視頻圖像處理方面，通過兩種方式來保證傳輸的視頻圖像的高質量、美觀性，一方面，利用視頻抖動緩沖器來減小由于抖動和丟包帶來的影響，另一方面對采集到的圖像進行顏色增強、降噪等處理來提升圖像清晰度。
l 網絡傳輸
網絡傳輸負責音視頻數據的傳輸，通過一套完整的傳輸框架，解決了音視頻數據的加密傳輸和防火墻穿透問題。一方面，通過SRTP協議保證音視頻數據在加密的狀態下進行傳輸，另一方面，通過整合了STUN和TURN的ICE協議來保證音視頻數據可以突破防火墻和NAT網絡的限制。
部分協議比較
RTMP和HTTP-FLV都是建立在FLV封裝之上的。RTMP一般用作直播源推流，HTTP-FLV一般用作直播觀看。RTMP 協議為流媒體而設計，在推流中用的比較多，同時大多 CDN 廠商支持RTMP 協議。
HTTP-FLV 使用類似 RTMP流式的 HTTP 長連接，需由特定流媒體服務器分發的，兼顧兩者的優點。以及可以復用現有 HTTP 分發資源的流式協議。它的實時性和 RTMP 相等，與 RTMP 相比又省去了部分協議交互時間，首屏時間更短，可拓展的功能也更多。
HLS 作為蘋果提出的直播協議，在 iOS 端占據了不可撼動的地位，Android 端也同時提供相應的支持。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
