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

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

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

為了降低頭部體積，需要進(jìn)行視頻本身的物理分段等等。對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對組成。

流媒體傳輸類型

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

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

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

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

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

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

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

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

流媒體協(xié)議原理

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

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

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

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

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

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

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

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

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

分發(fā)原理

數(shù)據(jù)經(jīng)以上三部分處理后為.ts文件（媒體數(shù)據(jù)）及.m3u8文件（媒體數(shù)據(jù)索引）存在于服務(wù)器之上。 客戶端訪問.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ù)這個文件，播放器會依次下載sample_100k-1.ts，sample_100k-2.ts，sample_100k-3.ts

HLS的文件點(diǎn)播

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

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

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

HLS的實(shí)況直播

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

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

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

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

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

RTMP(Real Time Messaging Protocol)

是Adobe Systems公司為Flash播放器和服務(wù)器之間音頻、視頻和數(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)絡(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片段，通過RTMP流上傳到服務(wù)器

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

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

(四)RTSP協(xié)議

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

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

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

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

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

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

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

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

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

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

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

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

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

(2) PLAY與RECORD：啟動SETUP分配流的數(shù)據(jù)傳輸。

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

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

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

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é)議采用滑動窗口控制機(jī)制，數(shù)據(jù)傳送隨著流控窗口動態(tài)的啟動和關(guān)閉，難以滿足流媒體實(shí)時和等時的傳送要求。UDP協(xié)議的無連接特點(diǎn)能夠提高傳輸速率，雖然可以在某種程度上滿足流媒體的實(shí)時性要求，但是由于其本身的不可靠性，也無法滿足流媒體傳輸?shù)男枰?/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一、單播：

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

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

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

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

單播的缺點(diǎn)：

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

二、 廣播：

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

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

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

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

廣播的缺點(diǎn)：

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

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

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

三、組播：

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

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

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

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

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

組播的缺點(diǎn)：

1．與單播協(xié)議相比沒有糾錯機(jī)制，發(fā)生丟包錯包后難以彌補(bǔ)，但可以通過一定的容錯機(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ù)。過去的流媒體技術(shù)多使用 RTP/RTSP，但現(xiàn)在的技術(shù)則大多基于 HTTP，并為更高效在大型分布式HTTP網(wǎng)絡(luò)（例如互聯(lián)網(wǎng)）分發(fā)而設(shè)計。

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

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

使用 HTTP 傳送視頻流；

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

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

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

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

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

Adaptive streaming overview

Adaptive streaming in action

MPEG-DASH (Dynamic Adaptive Streaming over HTTP)

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

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

可用的 MPEG-DASH 實(shí)現(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)關(guān)和CDN的緩存，從而顯著降低源服務(wù)器的負(fù)載。

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

Apple HLS (HTTP Live Streaming)

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

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

HLS 串流使用擴(kuò)展名為 .m3u8 的文件作為索引，文件切片格式為TS，支持直播和時移。支持的客戶端包括 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 中，微軟引入了一項使 Live Smooth Streaming H.264/AAC 視頻動態(tài)封裝成 Apple HLS 格式的功能，直接提供給 iOS 設(shè)備，而不需要再次編碼。同時支持直播和點(diǎn)播把1080P全高清視頻發(fā)送到Silverlight客戶端。

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

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

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

圖1 ：單一流媒體服務(wù)的架構(gòu)圖

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

1） 視頻存儲的壓力很大

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

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

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

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

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

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

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

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