著互聯(lián)網(wǎng)行業(yè)的火爆發(fā)展，云計(jì)算行業(yè)也緊跟勢(shì)頭，進(jìn)行快速發(fā)展階段。作為互聯(lián)網(wǎng)巨頭的網(wǎng)易也抓住此次機(jī)遇，對(duì)外推出了視頻云服務(wù)。在此前，網(wǎng)易視頻云（http://vcloud.163.com）服務(wù)已經(jīng)廣泛運(yùn)用于網(wǎng)易內(nèi)部產(chǎn)品，比如網(wǎng)易BOBO，網(wǎng)易蜂巢，網(wǎng)易公開(kāi)課等。4月6日，網(wǎng)易新聞客戶端和糗事百科合作進(jìn)行的直播也是通過(guò)網(wǎng)易視頻云接入并進(jìn)行直播。目前，網(wǎng)易視頻云服務(wù)的點(diǎn)播與直播功能均已上線，視頻云也廣泛應(yīng)用于遠(yuǎn)程醫(yī)療，在線教育，秀場(chǎng)直播、企業(yè)協(xié)作、遠(yuǎn)程監(jiān)控等領(lǐng)域。在此，網(wǎng)易視頻云的技術(shù)專(zhuān)家也給大家分享一些大家都關(guān)注的視頻技術(shù)內(nèi)容，后期也會(huì)陸續(xù)分享，感興趣的朋友們也可以多關(guān)注網(wǎng)易視頻云官方網(wǎng)站，后期會(huì)推出更多的內(nèi)容分享。

多媒體數(shù)據(jù)文件

一個(gè)完整的多媒體文件是由音頻和視頻兩部分組成的，H264、Xvid等就是視頻編碼格式，MP3、AAC等就是音頻編碼格式，字幕文件只是附加文件。目前大部分的播放器產(chǎn)品對(duì)于H.264 + AAC的MP4編碼格式支持最好，但是MP4也有很多的缺點(diǎn)，比如視頻header很大，影響在線視頻網(wǎng)站的初次加載時(shí)間。

為了降低頭部體積，需要進(jìn)行視頻本身的物理分段等等。對(duì)MPEG2-TS格式視頻文件進(jìn)行物理切片，分成一小段，這種方式被Apple公司的HTTP Live Streaming (HLS)技術(shù)采用。另外一種是使用Fragmented MP4文件格式，這是一種文件內(nèi)部的邏輯分割方式，而視頻文件還是完整的，這種技術(shù)被Microsoft Smooth Streaming和Adobe HTTP Dynamic Streaming采用。很多在線視頻網(wǎng)站在帶寬耗費(fèi)的壓力下，主要選擇的是adobe公司提供的FLV或F4V， FLV是流媒體封裝格式，可將其數(shù)據(jù)看為二進(jìn)制字節(jié)流。總體上看，F(xiàn)LV包括文件頭（File Header）和文件體（File Body）兩部分，其中文件體由一系列的Tag及Tag Size對(duì)組成。

流媒體傳輸類(lèi)型

流媒體在播放前不是完全下載整個(gè)文件，而是把開(kāi)始部分內(nèi)容存入內(nèi)存，數(shù)據(jù)流是隨時(shí)傳送隨時(shí)播放。

流媒體服務(wù)器提供的流式傳輸方式有兩種：順序流式傳輸和實(shí)時(shí)流式傳輸兩種方式。

順序流式傳輸是順序下載，在下載文件的同時(shí)用戶可觀看在線媒體。如果使用普通的HTTP服務(wù)器，將音視頻數(shù)據(jù)以從頭至尾方式發(fā)送，則為順序流媒體傳輸。實(shí)時(shí)流式傳輸總是實(shí)時(shí)傳送，特別適合現(xiàn)場(chǎng)事件。一般來(lái)說(shuō)，如果視頻為現(xiàn)場(chǎng)直播，或使用專(zhuān)用的流媒體服務(wù)器，或應(yīng)用如RTSP等專(zhuān)用實(shí)時(shí)協(xié)議，即為實(shí)時(shí)流媒體傳輸。實(shí)時(shí)流式傳輸必須匹配連接帶寬，這意味著圖像質(zhì)量會(huì)因網(wǎng)絡(luò)速度降低而變差。

在流式傳輸時(shí)，流媒體數(shù)據(jù)具有實(shí)時(shí)性，等時(shí)性等基本特點(diǎn)，流服務(wù)期和客戶終端要保證各種媒體間的同步關(guān)系，因此，流媒體傳輸對(duì)“最大延時(shí)”，“延時(shí)抖動(dòng)”等QoS參數(shù)都有嚴(yán)格要求。

實(shí)時(shí)流傳輸既可傳輸實(shí)況直播，也可傳輸完整的音視頻文件（專(zhuān)用協(xié)議流式）。

順序流媒體不可用于實(shí)況直播，僅能傳輸完整的音視頻文件（HTTP漸進(jìn)式）。

主流的流媒體協(xié)議

主流的流媒體協(xié)議主要有： RTMP， HLS， RTSP等。

流媒體協(xié)議原理

(一)HTTP漸進(jìn)式下載原理（僅支持文件播放）

HTTP邊下載邊播放，嚴(yán)格意義上講，不是直播協(xié)議。他的原理是先下載文件的基本信息，音頻視頻的時(shí)間戳，再下載音視頻數(shù)據(jù)，以播放mp4為例，先下載文件頭，根據(jù)文件頭指引下載文件尾，然后再下載文件的音視頻數(shù)據(jù)。

播放方式：瀏覽器調(diào)用系統(tǒng)播放器播放；

使HTML5的Video標(biāo)簽，瀏覽器支持直接播放。

(二)蘋(píng)果支持的HLS原理（實(shí)況直播、文件點(diǎn)播）

服務(wù)器端有三個(gè)組件：

其一：編碼器（media encoder）, 用于將設(shè)備輸出的格式轉(zhuǎn)為H264和AAC，并封裝為MPEG-2傳輸流；

其二：流分段器（stream segmenter）, 用于實(shí)況直播，將MPEG-2流分割為多個(gè)小片段后輸出；

其三：文件分段器（file segmenter）, 用于文件點(diǎn)播，將文件分隔為多個(gè)小片段后輸出；

分發(fā)原理

數(shù)據(jù)經(jīng)以上三部分處理后為.ts文件（媒體數(shù)據(jù)）及.m3u8文件（媒體數(shù)據(jù)索引）存在于服務(wù)器之上。 客戶端訪問(wèn).m3u8后按索引下載.ts文件進(jìn)行播放。

下面為某m3u8文件內(nèi)容：

#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ù)這個(gè)文件，播放器會(huì)依次下載sample_100k-1.ts，sample_100k-2.ts，sample_100k-3.ts

HLS的文件點(diǎn)播

1.使用蘋(píng)果開(kāi)發(fā)工具“文件分段器”將基于H264和AAC或MP3的MPEG4分段，

生成.ts和.m3u8文件，存儲(chǔ)于普通服務(wù)器上。

2.蘋(píng)果應(yīng)用程序或蘋(píng)果瀏覽器可以通過(guò)訪問(wèn).m3u8文件獲取到索引，并下載所需要的數(shù)據(jù)片段來(lái)播放。

HLS的實(shí)況直播

1.使用蘋(píng)果開(kāi)發(fā)工具“流分段器”將基于H264、AAC、MP3的MPEG2傳輸流分段，

可使用其它工具將MPEG4音視頻文件加載到MPEG2傳輸流當(dāng)中。

生成.ts和.m3u8文件，存儲(chǔ)于普通服務(wù)器上。

2.蘋(píng)果應(yīng)用程序或蘋(píng)果瀏覽器可以通過(guò)訪問(wèn).m3u8文件獲取到索引，并下載所需要的數(shù)據(jù)片段來(lái)播放。

(三)Adobe Flash支持的RTMP協(xié)議（支持文件播放 和 實(shí)況直播）

RTMP(Real Time Messaging Protocol)

是Adobe Systems公司為Flash播放器和服務(wù)器之間音頻、視頻和數(shù)據(jù)傳輸 開(kāi)發(fā)的開(kāi)放協(xié)議。

它有四種變種：

1)工作在TCP之上的明文協(xié)議，使用端口1935；

2)RTMPS通過(guò)TLS/SSL連接；

3)RTMPT封裝在HTTP請(qǐng)求之中，可穿越防火墻；

4)RTMPS類(lèi)似RTMPT，但使用的是HTTPS連接；

RTMP協(xié)議(Real Time Messaging Protocol)是被Flash用于對(duì)象,視頻,音頻的傳輸。這個(gè)協(xié)議建立在TCP協(xié)議或者輪詢HTTP協(xié)議之上。RTMP協(xié)議就像一個(gè)用來(lái)裝數(shù)據(jù)包的容器,這些數(shù)據(jù)既可以是AMF格式的數(shù)據(jù),也可以是FLV中的視/音頻數(shù)據(jù)。一個(gè)單一的連接可以通過(guò)不同的通道傳輸多路網(wǎng)絡(luò)流，這些通道中的包都是按照固定大小的包傳輸?shù)摹?/p>

必須采用Flash服務(wù)器FMS(Flash Media Server) 或 RED5.

FMS的文件點(diǎn)播

1.服務(wù)器將F4v 或 Flv文件轉(zhuǎn)化為RTMP流或HTTP流

2.客戶端獲取RTMP流，提取相應(yīng)的Flv 或 F4v文件片段進(jìn)行播放。

FMS的實(shí)況直播

1.設(shè)備端將數(shù)據(jù)轉(zhuǎn)化為F4v片段，通過(guò)RTMP流上傳到服務(wù)器

2.服務(wù)器轉(zhuǎn)發(fā)RTMP流到客戶端

3.客戶端獲取RTMP流，提取數(shù)據(jù)片段播放。

(四)RTSP協(xié)議

該協(xié)議用于C/S模型，是一個(gè)基于文本的協(xié)議，用于在客戶端和服務(wù)器端建立和協(xié)商實(shí)時(shí)流會(huì)話。

實(shí)時(shí)流協(xié)議（RTSP）是應(yīng)用級(jí)協(xié)議，控制實(shí)時(shí)數(shù)據(jù)的發(fā)送。RTSP提供了一個(gè)可擴(kuò)展框架，使實(shí)時(shí)數(shù)據(jù)，如音頻與視頻的受控點(diǎn)播成為可能。數(shù)據(jù)源包括現(xiàn)場(chǎng)數(shù)據(jù)與存儲(chǔ)在剪輯中數(shù)據(jù)。該協(xié)議目的在于控制多個(gè)數(shù)據(jù)發(fā)送連接，為選擇發(fā)送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP上發(fā)送機(jī)制提供方法。

實(shí)時(shí)流協(xié)議（RTSP）建立并控制一個(gè)或幾個(gè)時(shí)間同步的連續(xù)流媒體。盡管連續(xù)媒體流與控制流交換是可能的，通常它本身并不發(fā)送連續(xù)流。換言之，RTSP充當(dāng)多媒體服務(wù)器的網(wǎng)絡(luò)遠(yuǎn)程控制。RTSP連接沒(méi)有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用戶可打開(kāi)或關(guān)閉多個(gè)對(duì)服務(wù)器的可傳輸連接以發(fā)出RTSP請(qǐng)求。此外，可使用無(wú)連接傳輸協(xié)議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續(xù)媒體的傳輸機(jī)制。

協(xié)議支持的操作如下：

(1）從媒體服務(wù)器上檢索媒體：用戶可通過(guò)HTTP或其它方法提交一個(gè)演示描述。如演示是組播，演示式就包含用于連續(xù)媒體的的組播地址和端口。如演示僅通過(guò)單播發(fā)送給用戶，用戶為了安全應(yīng)提供目的地址。

(2）媒體服務(wù)器邀請(qǐng)進(jìn)入會(huì)議：媒體服務(wù)器可被邀請(qǐng)參加正進(jìn)行的會(huì)議，或回放媒體，或記錄其中一部分，或全部。這種模式在分布式教育應(yīng)用上很有用，會(huì)議中幾方可輪流按遠(yuǎn)程控制按鈕。

(3）將媒體加到現(xiàn)成講座中：如服務(wù)器告訴用戶可獲得附加媒體內(nèi)容，對(duì)現(xiàn)場(chǎng)講座顯得尤其有用。如HTTP/1.1中類(lèi)似，RTSP請(qǐng)求可由代理、通道與緩存處理。

下面區(qū)分幾種操作模式。

(1）單播：用戶選擇的端口號(hào)將媒體發(fā)送到RTSP請(qǐng)求源。

(2）服務(wù)器選擇地址多播：媒體服務(wù)器選擇多播地址和端口，這是現(xiàn)場(chǎng)直播或準(zhǔn)點(diǎn)播常用的方式。

(3）用戶選擇地址多播：如服務(wù)器加入正在進(jìn)行的多播會(huì)議，多播地址、端口和密鑰由會(huì)議描述給出。

RTSP控制通過(guò)單獨(dú)協(xié)議發(fā)送的數(shù)據(jù)流，與控制通道無(wú)關(guān)。例如，RTSP控制可通過(guò)TCP連接，而數(shù)據(jù)流通過(guò)UDP。因此，即使媒體服務(wù)器沒(méi)有收到請(qǐng)求，數(shù)據(jù)也會(huì)繼續(xù)發(fā)送。在連接生命期，單個(gè)媒體流可通過(guò)不同TCP連接順序發(fā)出請(qǐng)求來(lái)控制。所以，服務(wù)器需要維持能聯(lián)系流與RTSP請(qǐng)求的連接狀態(tài)。RTSP中很多方法與狀態(tài)無(wú)關(guān)，但下列方法在定義服務(wù)器流資源的分配與應(yīng)用上起著重要的作用：

(1) SETUP：讓服務(wù)器給流分配資源，啟動(dòng)RTSP連接。

(2) PLAY與RECORD：?jiǎn)?dòng)SETUP分配流的數(shù)據(jù)傳輸。

(3) PAUSE：臨時(shí)停止流，而不釋放服務(wù)器資源。

(4) TEARDOWN：釋放流的資源，RTSP連接停止。

標(biāo)識(shí)狀態(tài)的RTSP方法使用連接頭段識(shí)別RTSP連接，為響應(yīng)SETUP請(qǐng)求，服務(wù)器連接產(chǎn)生連接標(biāo)識(shí)。

RTSP為純粹的傳輸控制協(xié)議。

RTSP協(xié)議本身不與它負(fù)載的媒體數(shù)據(jù)相關(guān)。

RTSP協(xié)議需要自定義客戶端向服務(wù)器發(fā)送RTSP命令。

流媒體服務(wù)器的協(xié)議棧

在TCP／IP參考模型中，傳輸層通信協(xié)議TCP和UDP都不能滿足流媒體傳輸?shù)腝oS要求。由于TCP協(xié)議采用滑動(dòng)窗口控制機(jī)制，數(shù)據(jù)傳送隨著流控窗口動(dòng)態(tài)的啟動(dòng)和關(guān)閉，難以滿足流媒體實(shí)時(shí)和等時(shí)的傳送要求。UDP協(xié)議的無(wú)連接特點(diǎn)能夠提高傳輸速率，雖然可以在某種程度上滿足流媒體的實(shí)時(shí)性要求，但是由于其本身的不可靠性，也無(wú)法滿足流媒體傳輸?shù)男枰?/p>

針對(duì)傳輸層協(xié)議的矛盾，為了實(shí)現(xiàn)流媒體在IP上的實(shí)時(shí)傳送播放，設(shè)計(jì)流媒體服務(wù)器時(shí)需要在傳輸層協(xié)議（TCP／UDP）和應(yīng)用層之間增加一個(gè)通信控制層。在增加的通信控制層，采用相應(yīng)的實(shí)時(shí)傳輸協(xié)議，主要有：數(shù)據(jù)流部分的實(shí)時(shí)傳輸協(xié)議RTP（Real－time Transport Protocol），用于控制部分的實(shí)時(shí)傳輸控制協(xié)議RTCP（Real－time Control Protocol）和實(shí)時(shí)流化協(xié)議RTSP（Real－time Streaming Protocol）。

流媒體服務(wù)器的協(xié)議棧，如圖1所示。

RTP協(xié)議主要是用來(lái)傳送實(shí)時(shí)的流媒體信息，數(shù)據(jù)報(bào)主要包括多媒體數(shù)據(jù)，以及所攜帶負(fù)載的時(shí)間戳，順序號(hào)等。

RTCP協(xié)議的數(shù)據(jù)報(bào)主要包括了接收者收到某個(gè)多媒體流的服務(wù)質(zhì)量信息Qos，用于對(duì)服務(wù)器端的反饋。

RTSP是一種控制協(xié)議，包括通信連接前的設(shè)定，從服務(wù)器送出的多媒體資料的控制。用于控制具有實(shí)時(shí)性的數(shù)據(jù)傳輸。它提供對(duì)流媒體的類(lèi)似VCR（Video Cassette Recorder）的控制功能，如播放、暫停、快進(jìn)、錄制等，也就是RTSP對(duì)多媒體服務(wù)器實(shí)施網(wǎng)絡(luò)遠(yuǎn)程控制。

流媒體服務(wù)器的功能框圖，如圖2所示。

當(dāng)服務(wù)器收到RTSP請(qǐng)求，它首先產(chǎn)生RTSP請(qǐng)求對(duì)象。服務(wù)器通過(guò)RTSP協(xié)議的應(yīng)答信息將請(qǐng)求的內(nèi)容以流會(huì)話（streaming session）的形式描述，內(nèi)容包括數(shù)據(jù)流包含多少個(gè)流、媒體類(lèi)型、和編解碼格式。一個(gè)流會(huì)話由一個(gè)或多個(gè)數(shù)據(jù)流組成，如視頻流和音頻流等。實(shí)際的數(shù)據(jù)流通過(guò)RTP協(xié)議傳遞到客戶端。RTP在一對(duì)一或一對(duì)多的傳輸情況下工作，其目的是提供時(shí)間信息和實(shí)現(xiàn)流同步。RTP本身并不能為順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，它依靠RTCP一起提供流量控制和擁塞控制服務(wù)。在RTP會(huì)話期間，各連接者監(jiān)視下層網(wǎng)絡(luò)的性能，并將相關(guān)信息放入RTCP包，周期性地傳送RTCP包來(lái)通知發(fā)送方。發(fā)送方也可以用RTCP包提供每次的會(huì)話信息，包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料。因此，服務(wù)器可以利用這些信息動(dòng)態(tài)地改變傳輸速率，甚至改變有效載荷類(lèi)型。RTP和RTCP配合使用，因有效的反饋和最小的開(kāi)銷(xiāo)使傳輸效率最佳化。

通過(guò)流媒體服務(wù)器的協(xié)議棧的設(shè)計(jì)，可以明確流媒體服務(wù)器是在傳輸層協(xié)議（TCP，UDP）上解釋RTP，RTCP，RTSP協(xié)議的，所有的客戶連接請(qǐng)求都是以TCP的端口獲得的，流媒體數(shù)據(jù)也都是打成RTP包，通過(guò)UDP端口發(fā)出去的，因此，對(duì)于TCP，UDP端口事件的調(diào)度以及如何把大量的流媒體數(shù)據(jù)從磁盤(pán)空間傳遞到網(wǎng)絡(luò)上成為制約流媒體服務(wù)器性能的主要因素。

傳統(tǒng)流媒體服務(wù)器的處理流程，如圖3所示。

流媒體服務(wù)器面對(duì)一個(gè)單一的客戶，完成的過(guò)程如下：

1）在客戶端發(fā)出RTSP連接請(qǐng)求后，服務(wù)器通過(guò)對(duì)TCP端口的監(jiān)聽(tīng)，讀入請(qǐng)求。

2）解析請(qǐng)求內(nèi)容，調(diào)入相應(yīng)的流媒體文件。

3）形成RTP包，分發(fā)數(shù)據(jù)流包，獲得RTCP包。

4）數(shù)據(jù)包發(fā)送完畢，關(guān)閉連接。

上圖是RTSP直播服務(wù)器的系統(tǒng)框圖。

從攝像頭采集實(shí)時(shí)圖像，送到編碼器進(jìn)行實(shí)時(shí)編碼，一般是生成TS格式的數(shù)據(jù)流，然后數(shù)據(jù)流輸出到視頻直播服務(wù)器。客戶端先發(fā)送請(qǐng)求到web服務(wù)器，然后再重定向到RTSP視頻服務(wù)器，從視頻服務(wù)器讀取數(shù)據(jù)，同時(shí)實(shí)現(xiàn)播放，暫停等功能。

流媒體的傳輸技術(shù)

一、單播：

主機(jī)之間“一對(duì)一”的通訊模式，網(wǎng)絡(luò)中的交換機(jī)和路由器對(duì)數(shù)據(jù)只進(jìn)行轉(zhuǎn)發(fā)不進(jìn)行復(fù)制。如果10個(gè)客戶機(jī)需要相同的數(shù)據(jù)，則服務(wù)器需要逐一傳送，重復(fù)10次相同的工作。但由于其能夠針對(duì)每個(gè)客戶的及時(shí)響應(yīng)，所以現(xiàn)在的網(wǎng)頁(yè)瀏覽全部都是采用IP單播協(xié)議。網(wǎng)絡(luò)中的路由器和交換機(jī)根據(jù)其目標(biāo)地址選擇傳輸路徑，將IP單播數(shù)據(jù)傳送到其指定的目的地。

單播的優(yōu)點(diǎn)：

1. 服務(wù)器及時(shí)響應(yīng)客戶機(jī)的請(qǐng)求

2. 服務(wù)器針對(duì)每個(gè)客戶不通的請(qǐng)求發(fā)送不通的數(shù)據(jù)，容易實(shí)現(xiàn)個(gè)性化服務(wù)。

單播的缺點(diǎn)：

1. 服務(wù)器針對(duì)每個(gè)客戶機(jī)發(fā)送數(shù)據(jù)流，服務(wù)器流量＝客戶機(jī)數(shù)量×客戶機(jī)流量；在客戶數(shù)量大、每個(gè)客戶機(jī)流量大的流媒體應(yīng)用中服務(wù)器不堪重負(fù)。

二、 廣播：

主機(jī)之間“一對(duì)所有”的通訊模式，網(wǎng)絡(luò)對(duì)其中每一臺(tái)主機(jī)發(fā)出的信號(hào)都進(jìn)行無(wú)條件復(fù)制并轉(zhuǎn)發(fā)，所有主機(jī)都可以接收到所有信息（不管你是否需要），由于其不用路徑選擇，所以其網(wǎng)絡(luò)成本可以很低廉。在數(shù)據(jù)網(wǎng)絡(luò)中也允許廣播的存在，但其被限制在二層交換機(jī)的局域網(wǎng)范圍內(nèi)，禁止廣播數(shù)據(jù)穿過(guò)路由器，防止廣播數(shù)據(jù)影響大面積的主機(jī)。

廣播的優(yōu)點(diǎn)：

1. 網(wǎng)絡(luò)設(shè)備簡(jiǎn)單，維護(hù)簡(jiǎn)單，布網(wǎng)成本低廉

2. 由于服務(wù)器不用向每個(gè)客戶機(jī)單獨(dú)發(fā)送數(shù)據(jù)，所以服務(wù)器流量負(fù)載極低。

廣播的缺點(diǎn)：

1.無(wú)法針對(duì)每個(gè)客戶的要求和時(shí)間及時(shí)提供個(gè)性化服務(wù)。

2. 網(wǎng)絡(luò)允許服務(wù)器提供數(shù)據(jù)的帶寬有限，客戶端的最大帶寬＝服務(wù)總帶寬。

3. 廣播禁止在Internet寬帶網(wǎng)上傳輸。

三、組播：

主機(jī)之間“一對(duì)一組”的通訊模式，也就是加入了同一個(gè)組的主機(jī)可以接受到此組內(nèi)的所有數(shù)據(jù)，網(wǎng)絡(luò)中的交換機(jī)和路由器只向有需求者復(fù)制并轉(zhuǎn)發(fā)其所需數(shù)據(jù)。主機(jī)可以向路由器請(qǐng)求加入或退出某個(gè)組，網(wǎng)絡(luò)中的路由器和交換機(jī)有選擇的復(fù)制并傳輸數(shù)據(jù)，即只將組內(nèi)數(shù)據(jù)傳輸給那些加入組的主機(jī)。這樣既能一次將數(shù)據(jù)傳輸給多個(gè)有需要（加入組）的主機(jī)，又能保證不影響其他不需要（未加入組）的主機(jī)的其他通訊。

組播的優(yōu)點(diǎn)：

1. 需要相同數(shù)據(jù)流的客戶端加入相同的組共享一條數(shù)據(jù)流，節(jié)省了服務(wù)器的負(fù)載。具備廣播所具備的優(yōu)點(diǎn)。

2. 由于組播協(xié)議是根據(jù)接受者的需要對(duì)數(shù)據(jù)流進(jìn)行復(fù)制轉(zhuǎn)發(fā)，所以服務(wù)端的服務(wù)總帶寬不受客戶接入端帶寬的限制。

3. 此協(xié)議和單播協(xié)議一樣允許在Internet寬帶網(wǎng)上傳輸。

組播的缺點(diǎn)：

1．與單播協(xié)議相比沒(méi)有糾錯(cuò)機(jī)制，發(fā)生丟包錯(cuò)包后難以彌補(bǔ)，但可以通過(guò)一定的容錯(cuò)機(jī)制和QOS加以彌補(bǔ)。

2．現(xiàn)行網(wǎng)絡(luò)雖然都支持組播的傳輸，但在客戶認(rèn)證、QOS等方面還需要完善，這些缺點(diǎn)在理論上都有成熟的解決方案，只是需要逐步推廣應(yīng)用到現(xiàn)存網(wǎng)絡(luò)當(dāng)中。

自適性串流技術(shù)

自適性串流（ABS - adaptive bitrate streaming），是一種在電腦網(wǎng)絡(luò)使用的一種串流技術(shù)。過(guò)去的流媒體技術(shù)多使用 RTP/RTSP，但現(xiàn)在的技術(shù)則大多基于 HTTP，并為更高效在大型分布式HTTP網(wǎng)絡(luò)（例如互聯(lián)網(wǎng)）分發(fā)而設(shè)計(jì)。

此技術(shù)根據(jù)實(shí)時(shí)檢測(cè)的用戶的帶寬和CPU使用率，調(diào)整視頻流的質(zhì)量。這需要使用一種可以將單一視頻源輸出為多碼率的編碼器。播放器客戶端依賴可用資源在不同碼率的流之間切換。"結(jié)果就是：更少緩存、更快的開(kāi)始播放、為低端和高端鏈接都提供良好的體驗(yàn)。

根據(jù)當(dāng)前廣泛使用的實(shí)現(xiàn)，更具體來(lái)說(shuō)，自適應(yīng)串流（ABS）：

使用 HTTP 傳送視頻流；

使用多碼率編碼源內(nèi)容；

每個(gè)單碼率的流被切成小的，幾秒鐘的小切片；

流媒體客戶端首先獲取所有碼率的切片索引信息。一開(kāi)始，客戶端先請(qǐng)求最低碼率的串流。如果客戶端判斷下載速度比當(dāng)前碼率的切片串流快，它就去請(qǐng)求下一個(gè)更高碼率的串流。隨著播放的進(jìn)行，如果客戶端發(fā)現(xiàn)下載速度比當(dāng)前碼率的切片串流慢，轉(zhuǎn)而請(qǐng)求下一個(gè)較低碼率的串流。

切片大小和具體實(shí)現(xiàn)密切相關(guān)，不過(guò)一般都在2～10秒之間。每個(gè)切片由一個(gè)完整的GOP序列組成，一個(gè)GOP序列里面有1個(gè)或者多個(gè)I幀，GOP序列的第一個(gè)幀必須是I幀，并且每個(gè)切片都能單獨(dú)的解碼播放顯示。

與傳統(tǒng)的流媒體技術(shù)比較，缺點(diǎn)：需要額外的存儲(chǔ)，更多的編碼代價(jià)，復(fù)雜的只適應(yīng)碼率邏輯。

Adaptive streaming overview

Adaptive streaming in action

MPEG-DASH (Dynamic Adaptive Streaming over HTTP)

MPEG-DASH 是基于HTTP的自適應(yīng)串流方案中的唯一國(guó)際標(biāo)準(zhǔn)。MPEG-DASH 技術(shù)由 MPEG 主導(dǎo)開(kāi)發(fā)：

2010年開(kāi)始DASH相關(guān)工作，2011年1月成為國(guó)際標(biāo)準(zhǔn)草案，2011年11月成為國(guó)際標(biāo)準(zhǔn)[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ú)線網(wǎng)絡(luò)。

可用的 MPEG-DASH 實(shí)現(xiàn)有：

bitmovin GmbH 的開(kāi)源 DASH 客戶端庫(kù) libdash 和 DASHEncoder

Adobe HDS (HTTP Dynamic Streaming)

Flash Player 和 Flash Media Server 的最新版支持傳統(tǒng)的 RTMP 協(xié)議和 HTTP協(xié)議。后者和Apple和微軟基于HTTP的方案類(lèi)似。

基于HTTP的流的優(yōu)勢(shì)是：

不需要防火墻開(kāi)普通web瀏覽器所需端口以外的任何端口

允許視頻切片在瀏覽器、網(wǎng)關(guān)和CDN的緩存，從而顯著降低源服務(wù)器的負(fù)載。

HDS 的文件格式為 FLV/F4V/MP4，索引文件為 f4m，同時(shí)支持直播和時(shí)移。

Apple HLS (HTTP Live Streaming)

是一種基于HTTP的媒體流通信協(xié)議，在 iPhone 3.0 及更新版中成為標(biāo)準(zhǔn)功能。

2010年10月，所有自適應(yīng)串流方案都作為產(chǎn)權(quán)提供時(shí)，Apple 將HLS提交到 IETF，成為正式的 RFC.

HLS 串流使用擴(kuò)展名為 .m3u8 的文件作為索引，文件切片格式為T(mén)S，支持直播和時(shí)移。支持的客戶端包括 iPad, iPhone, STB，VLC和其他支持的設(shè)備。

Microsoft MSS (Microsoft Smooth Streaming)

Smooth Streaming 是IIS的媒體服務(wù)擴(kuò)展，用于支持基于HTTP的自適應(yīng)串流。

在2010年11月發(fā)布的 IIS Media Services 4.0 中，微軟引入了一項(xiàng)使 Live Smooth Streaming H.264/AAC 視頻動(dòng)態(tài)封裝成 Apple HLS 格式的功能，直接提供給 iOS 設(shè)備，而不需要再次編碼。同時(shí)支持直播和點(diǎn)播把1080P全高清視頻發(fā)送到Silverlight客戶端。

MSS 的文件切片格式為 mp4（fragmented-mp4），索引文件為ism/ismc，同時(shí)支持直播和時(shí)移。

流行視頻網(wǎng)站的流媒體服務(wù)器架構(gòu)

為了能夠提供各類(lèi)設(shè)備的在線視頻播放需求，對(duì)于在線視頻流媒體服務(wù)，提出了很多需求，對(duì)于早期建立的視頻網(wǎng)站（土豆，優(yōu)酷，ku6等）都只提供一種視頻流媒體格式（FLV）的支持，我們稱之為單一的流媒體服務(wù)架構(gòu)，如圖：

圖1 ：?jiǎn)我涣髅襟w服務(wù)的架構(gòu)圖

但是，在實(shí)際業(yè)務(wù)運(yùn)營(yíng)中遇到了很多問(wèn)題：

1） 視頻存儲(chǔ)的壓力很大

同一種視頻碼流（h.264）,因?yàn)獒槍?duì)不同平臺(tái)應(yīng)用設(shè)備（如表2）的播放需求，需要不同的封裝格式，需要將產(chǎn)生大量重復(fù)視頻流存儲(chǔ)的壓力，視頻網(wǎng)站的視頻量巨大，多支持一種格式將產(chǎn)生幾百TB級(jí)的存儲(chǔ)壓力，從機(jī)房到機(jī)柜，視頻流同步等環(huán)節(jié)負(fù)載和壓力都是巨大的。

2） 封裝后的視頻格式是否真的被播放

視頻流封裝完成后，同步到各地的中心節(jié)點(diǎn)后，是否真的有視頻流請(qǐng)求產(chǎn)生，還是僅僅處于視頻準(zhǔn)備狀態(tài)，是否會(huì)影響中心節(jié)點(diǎn)的磁盤(pán)占用，緩存節(jié)點(diǎn)的命中率不高。

3） 封裝格式的功能性升級(jí)，導(dǎo)致老視頻再次封裝

封裝格式的不斷發(fā)展，TS流，HTTP live Stream的不斷優(yōu)化，將導(dǎo)致現(xiàn)有的視頻流不斷需要翻新或重復(fù)封裝。 為了解決上述各類(lèi)問(wèn)題，視頻網(wǎng)站流媒體服務(wù)的研發(fā)工程師進(jìn)行了多格式的流媒體服務(wù)架構(gòu)探索，提供了各類(lèi)視頻封裝格式的流媒體封裝反向代理接口，該接口能夠通過(guò)URL的請(qǐng)求，完成對(duì)特定視頻編碼格式（h.264）的封裝。

圖2：多格式的流媒體服務(wù)架構(gòu)：

如圖所示，“流媒體容器封裝服務(wù)“成為多格式視頻流服務(wù)的核心，對(duì)于這個(gè)流媒體的封裝服務(wù)，通過(guò)對(duì)h.264的視頻編碼流進(jìn)行不同格式的封裝，提供了多種視頻流的推送。對(duì)于這個(gè)服務(wù)，我們希望能夠盡快為視頻的cache服務(wù)推送視頻流，所以，在硬盤(pán)方面，選擇了每分鐘15000轉(zhuǎn)的SAS硬盤(pán)，降低同一視頻流的不同封裝請(qǐng)求的IO延遲等待。

作為最簡(jiǎn)單和原始的流媒體解決方案，單一流媒體服務(wù)架構(gòu)唯一顯著的優(yōu)點(diǎn)在于它僅需要維護(hù)一個(gè)標(biāo)準(zhǔn)的視頻流文件，而這樣的服務(wù)器基礎(chǔ)設(shè)施在互聯(lián)網(wǎng)中已經(jīng)普遍存在，其安裝和維護(hù)的工作量和復(fù)雜性比起多格式流媒體服務(wù)架構(gòu)來(lái)說(shuō)要簡(jiǎn)單和容易的多。然而其缺點(diǎn)和不足卻也很多，首先是維護(hù)的工作量較大，多份相同視頻文件由于封裝格式不相同，需要同時(shí)維護(hù)多個(gè)實(shí)體的碼流文件，大量的占用磁盤(pán)的空間，再次，轉(zhuǎn)碼集群需要針對(duì)多種不同的封裝格式，進(jìn)行多次的視頻轉(zhuǎn)碼，搶占很多資源，缺乏靈活的控制功能和擴(kuò)展機(jī)制。