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