網(wǎng)易視頻云流媒體服務(wù)器原理和架構(gòu)解析

1、一個完整的多媒體文件是由音頻和視頻兩部分組成的，H264、Xvid等就是視頻編碼格式，MP3、AAC等就是音頻編碼格式，字幕文件只是附加文件。目前大部分的播放器產(chǎn)品對于H.264 + AAC的MP4編碼格式支持最好，但是MP4也有很多的缺點，比如視頻header很大，影響在線視頻網(wǎng)站的初次加載時間。為了降低頭部體積，需要進行視頻本身的物理分段等等。對MPEG2-TS格式視頻文件進行物理切片，分成一小段，這種方式被Apple公司的HTTP Live Streaming (HLS)技術(shù)采用。另外一種是使用Fragmented MP4文件格式，這是一種文件內(nèi)部的邏輯分割方式，而視頻文件還是完整的，這

2、種技術(shù)被 Microsoft Smooth Streaming和Adobe HTTP Dynamic Streaming采用。很多在線視頻網(wǎng)站在帶寬耗費的壓力下，主要選擇的是adobe公司提供的FLV或F4V，F(xiàn)LV是流媒體封裝格式，可將其數(shù)據(jù)看為二進制字節(jié)流?？傮w上看，F(xiàn)LV包括文件頭（File Header）和文件體（File Body）兩部分，其中文件體由一系列的Tag及Tag Size對組成。流媒體傳輸類型流媒體在播放前不是完全下載整個文件，而是把開始部分內(nèi)容存入內(nèi)存，數(shù)據(jù)流是隨時傳送隨時播放。流媒體服務(wù)器提供的流式傳輸方式有兩種：順序流式傳輸和實時流式傳輸 兩種方

3、式。順序流式傳輸是順序下載，在下載文件的同時用戶可觀看在線媒體。如果使用普通的HTTP服務(wù)器，將音視頻數(shù)據(jù)以從頭至尾方式發(fā)送，則為順序流媒體傳輸。實時流式傳輸總是實時傳送，特別適合現(xiàn)場事件。一般來說，如果視頻為現(xiàn)場直播，或使用專用的流媒體服務(wù)器，或應(yīng)用如RTSP等專用實時協(xié)議，即為實時流媒體傳輸。實時流式傳輸必須匹配連接帶寬，這意味著圖像質(zhì)量會因網(wǎng)絡(luò)速度降低而變差。在流式傳輸時，流媒體數(shù)據(jù)具有實時性，等時性等基本特點，流服務(wù)期和客戶終端要保證各種媒體間的同步關(guān)系，因此，流媒體傳輸對“最大延時”，“延時抖動”等QoS參數(shù)都有嚴(yán)格要求。實時流傳輸既可傳輸實況直播，也可傳輸完整的音視頻文件（專用協(xié)議

4、流式）。     順序流媒體不可用于實況直播，僅能傳輸完整的音視頻文件（HTTP漸進式）。 區(qū)別實時流順序流音視頻數(shù)據(jù)源實時從錄制設(shè)備上采集，或（使用專用協(xié)議傳輸?shù)模┪募刹シ诺囊粢曨l文件服務(wù)器類型專用流媒體服務(wù)器，如：QuickTime Streaming ServerReal ServerWindows Media ServerFlash Media Server普通的HTTP服務(wù)器，或FTP服務(wù)器傳輸協(xié)議專用協(xié)議RTSP，HLS或RTMP等一般的HTTP協(xié)議，與傳輸網(wǎng)頁的協(xié)議相同跳播可隨機訪問任意片段在給定時刻，用戶只能觀看已下

5、載的那部分，而不能跳到還未下載的部分 主流的流媒體協(xié)議主流的流媒體協(xié)議主要有： RTMP， HLS， RTSP等。 區(qū)別RTMPHLSRTSP全稱Real Time Message ProtocolHttp Live StreamReal Time Streaming Protocol上層協(xié)議TCP或HTTPHTTPRTP，RTCP軟件模型CSBSCS研發(fā)主要來自AdobeAppleMicrosoft針對客戶端支持Flash類產(chǎn)品的瀏覽器支持HTML5的瀏覽器蘋果的Safari瀏覽器支持HTML5的瀏覽器播放器視頻格式要求FLV， F

6、4VMP4無服務(wù)器要求專用Flash服務(wù)器Flash Media ServerRed5普通HTTP服務(wù)器專用RTSP流媒體服務(wù)器實況直播要求專用編碼器上傳Flash Media Encoder專用編碼器上傳Apple開發(fā)工具與服務(wù)器相關(guān)，自定義上傳文件播放要求FLV ，F(xiàn)4V文件即可，服務(wù)器會自動分解為F4f 數(shù)據(jù)文件f4x索引文件TS數(shù)據(jù)文件，M3u8索引文件與服務(wù)器相關(guān)，與播放器相關(guān) 流媒體協(xié)議原理(一)  HTTP漸進式下載原理（僅支持文件播放）HTTP邊下載邊播放，嚴(yán)格意義上講，不是直播協(xié)議。他的原理是先下載文件的基本信息，音頻視頻的時

7、間戳，再下載音視頻數(shù)據(jù)，以播放mp4為例，先下載文件頭，根據(jù)文件頭指引下載文件尾，然后再下載文件的音視頻數(shù)據(jù)。播放方式：瀏覽器調(diào)用系統(tǒng)播放器播放；           使HTML5的Video標(biāo)簽，瀏覽器支持直接播放。 (二)  蘋果支持的HLS原理（實況直播、文件點播） 服務(wù)器端有三個組件：其一：編碼器（media encoder）, 用于將設(shè)備輸出的格式轉(zhuǎn)為H264和AAC，并封裝為MPEG-2傳輸流；其二：流分段器（stream segme

8、nter）, 用于實況直播，將MPEG-2流分割為多個小片段后輸出；其三：文件分段器（file segmenter）, 用于文件點播，將文件分隔為多個小片段后輸出；分發(fā)原理數(shù)據(jù)經(jīng)以上三部分處理后為.ts文件（媒體數(shù)據(jù)）及.m3u8文件（媒體數(shù)據(jù)索引）存在于服務(wù)器之上。 客戶端訪問.m3u8后按索引下載.ts文件進行播放。 下面為某m3u8文件內(nèi)容：#EXTM3U#EXT-X-TARGETDURATION:30#EXTINF:30,#EXTINF:30,#EXTINF:30,#EXT-X-ENDLIST     &#

9、160; HLS的文件點播1. 使用蘋果開發(fā)工具“文件分段器”將基于H264和AAC或MP3的MPEG4分段，生成.ts和.m3u8文件，存儲于普通服務(wù)器上。2. 蘋果應(yīng)用程序或蘋果瀏覽器可以通過訪問.m3u8文件獲取到索引，并下載所需要的數(shù)據(jù)片段來播放。     HLS的實況直播1.  使用蘋果開發(fā)工具“流分段器”將基于H264、AAC、MP3的MPEG2傳輸流分段，可使用其它工具將MPEG4音視頻文件加載到MPEG2傳輸流當(dāng)中。生成.ts和.m3u8文件，存儲于普通服務(wù)器上。2. 

10、 蘋果應(yīng)用程序或蘋果瀏覽器可以通過訪問.m3u8文件獲取到索引，并下載所需要的數(shù)據(jù)片段來播放。 (三) Adobe Flash 支持的RTMP協(xié)議（支持文件播放 和 實況直播）RTMP(Real Time Messaging Protocol) 是Adobe Systems公司為Flash播放器和服務(wù)器之間音頻、視頻和數(shù)據(jù)傳輸 開發(fā)的開放協(xié)議。它有四種變種：1)   工作在TCP之上的明文協(xié)議，使用端口1935；2)   RTMPS通過TLS/SSL連接；3)  &

11、#160;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ù)?。必須采用Flash服務(wù)器FMS(Flash Media Server) 或

12、60;RED5.FMS的文件點播1.   服務(wù)器將F4v 或 Flv文件轉(zhuǎn)化為RTMP流或HTTP流2.   客戶端獲取RTMP流，提取相應(yīng)的Flv 或 F4v文件片段進行播放。FMS的實況直播1.   設(shè)備端將數(shù)據(jù)轉(zhuǎn)化為F4v片段，通過RTMP流上傳到服務(wù)器2.   服務(wù)器轉(zhuǎn)發(fā)RTMP流到客戶端3.   客戶端獲取RTMP流，提取數(shù)據(jù)片段播放。  (四) RTSP協(xié)議該協(xié)議用

13、于C/S模型，是一個基于文本的協(xié)議，用于在客戶端和服務(wù)器端建立和協(xié)商實時流會話。實時流協(xié)議（RTSP）是應(yīng)用級協(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充當(dāng)多媒體服務(wù)器的網(wǎng)絡(luò)遠(yuǎn)程控制。RTSP連接沒有綁定到傳輸層連接，如TCP。在R

14、TSP連接期間，RTSP用戶可打開或關(guān)閉多個對服務(wù)器的可傳輸連接以發(fā)出RTSP請求。此外，可使用無連接傳輸協(xié)議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續(xù)媒體的傳輸機制。協(xié)議支持的操作如下：(1）從媒體服務(wù)器上檢索媒體：用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用于連續(xù)媒體的的組播地址和端口。如演示僅通過單播發(fā)送給用戶，用戶為了安全應(yīng)提供目的地址。(2）媒體服務(wù)器邀請進入會議：媒體服務(wù)器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分布式教育應(yīng)用上很有用，會議中幾方可輪流按遠(yuǎn)程控制按鈕。(3）將媒體加

15、到現(xiàn)成講座中：如服務(wù)器告訴用戶可獲得附加媒體內(nèi)容，對現(xiàn)場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。下面區(qū)分幾種操作模式。(1）單播：用戶選擇的端口號將媒體發(fā)送到RTSP請求源。(2）服務(wù)器選擇地址多播：媒體服務(wù)器選擇多播地址和端口，這是現(xiàn)場直播或準(zhǔn)點播常用的方式。(3）用戶選擇地址多播：如服務(wù)器加入正在進行的多播會議，多播地址、端口和密鑰由會議描述給出。 RTSP控制通過單獨協(xié)議發(fā)送的數(shù)據(jù)流，與控制通道無關(guān)。例如，RTSP控制可通過TCP連接，而數(shù)據(jù)流通過UDP。因此，即使媒體服務(wù)器沒有收到請求，數(shù)據(jù)也會繼續(xù)發(fā)送。在連接生命期，單個媒體流可通過

16、不同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é)議需要自定

17、義客戶端向服務(wù)器發(fā)送RTSP命令。 流媒體服務(wù)器的協(xié)議棧在TCPIP參考模型中，傳輸層通信協(xié)議TCP和UDP都不能滿足流媒體傳輸?shù)腝oS要求。由于TCP協(xié)議采用滑動窗口控制機制，數(shù)據(jù)傳送隨著流控窗口動態(tài)的啟動和關(guān)閉，難以滿足流媒體實時和等時的傳送要求。UDP協(xié)議的無連接特點能夠提高傳輸速率，雖然可以在某種程度上滿足流媒體的實時性要求，但是由于其本身的不可靠性，也無法滿足流媒體傳輸?shù)男枰?。針對傳輸層協(xié)議的矛盾，為了實現(xiàn)流媒體在IP上的實時傳送播放，設(shè)計流媒體服務(wù)器時需要在傳輸層協(xié)議（TCPUDP）和應(yīng)用層之間增加一個通信控制層。在增加的通信控制層，采用相應(yīng)的實時傳輸協(xié)議，主要有：數(shù)據(jù)流

18、部分的實時傳輸協(xié)議RTP（Realtime Transport Protocol），用于控制部分的實時傳輸控制協(xié)議RTCP（Realtime Control Protocol）和實時流化協(xié)議RTSP（Realtime Streaming Protocol）。 流媒體服務(wù)器的協(xié)議棧，如圖1所示。RTP協(xié)議主要是用來傳送實時的流媒體信息，數(shù)據(jù)報主要包括多媒體數(shù)據(jù)，以及所攜帶負(fù)載的時間戳，順序號等。RTCP協(xié)議的數(shù)據(jù)報主要包括了接收者收到某個多媒體流的服務(wù)質(zhì)量信息Qos，用于對服務(wù)器端的反饋。RTSP是一種控制協(xié)議，包括通信連接前的設(shè)定，從服務(wù)器送出的多媒體資料的控制。用于控制具有實時性的

19、數(shù)據(jù)傳輸。它提供對流媒體的類似VCR（Video Cassette Recorder）的控制功能，如播放、暫停、快進、錄制等，也就是RTSP對多媒體服務(wù)器實施網(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ù)據(jù)流通過RTP協(xié)議傳遞到客戶端。RTP在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現(xiàn)流同步。RT

20、P本身并不能為順序傳送數(shù)據(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

21、的端口獲得的，流媒體數(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)框圖。從攝像頭

22、采集實時圖像，送到編碼器進行實時編碼，一般是生成TS格式的數(shù)據(jù)流，然后數(shù)據(jù)流輸出到視頻直播服務(wù)器?？蛻舳讼劝l(fā)送請求到web服務(wù)器，然后再重定向到RTSP視頻服務(wù)器，從視頻服務(wù)器讀取數(shù)據(jù)，同時實現(xiàn)播放，暫停等功能。流媒體的傳輸技術(shù)一、單播：主機之間“一對一”的通訊模式，網(wǎng)絡(luò)中的交換機和路由器對數(shù)據(jù)只進行轉(zhuǎn)發(fā)不進行復(fù)制。如果10個客戶機需要相同的數(shù)據(jù)，則服務(wù)器需要逐一傳送，重復(fù)10次相同的工作。但由于其能夠針對每個客戶的及時響應(yīng)，所以現(xiàn)在的網(wǎng)頁瀏覽全部都是采用IP單播協(xié)議。網(wǎng)絡(luò)中的路由器和交換機根據(jù)其目標(biāo)地址選擇傳輸路徑，將IP單播數(shù)據(jù)傳送到其指定的目的地。單播的優(yōu)點：1. 服務(wù)器及時響

23、應(yīng)客戶機的請求2. 服務(wù)器針對每個客戶不通的請求發(fā)送不通的數(shù)據(jù)，容易實現(xiàn)個性化服務(wù)。單播的缺點：1. 服務(wù)器針對每個客戶機發(fā)送數(shù)據(jù)流，服務(wù)器流量客戶機數(shù)量×客戶機流量；在客戶數(shù)量大、每個客戶機流量大的流媒體應(yīng)用中服務(wù)器不堪重負(fù)。 二、 廣播：主機之間“一對所有”的通訊模式，網(wǎng)絡(luò)對其中每一臺主機發(fā)出的信號都進行無條件復(fù)制并轉(zhuǎn)發(fā)，所有主機都可以接收到所有信息（不管你是否需要），由于其不用路徑選擇，所以其網(wǎng)絡(luò)成本可以很低廉。在數(shù)據(jù)網(wǎng)絡(luò)中也允許廣播的存在，但其被限制在二層交換機的局域網(wǎng)范圍內(nèi)，禁止廣播數(shù)據(jù)穿過路由器，防止廣播數(shù)據(jù)影響大面積的主機。廣播的優(yōu)點：1.

24、 網(wǎng)絡(luò)設(shè)備簡單，維護簡單，布網(wǎng)成本低廉2. 由于服務(wù)器不用向每個客戶機單獨發(fā)送數(shù)據(jù)，所以服務(wù)器流量負(fù)載極低。廣播的缺點：1.無法針對每個客戶的要求和時間及時提供個性化服務(wù)。2. 網(wǎng)絡(luò)允許服務(wù)器提供數(shù)據(jù)的帶寬有限，客戶端的最大帶寬服務(wù)總帶寬。3. 廣播禁止在Internet寬帶網(wǎng)上傳輸。 三、組播：主機之間“一對一組”的通訊模式，也就是加入了同一個組的主機可以接受到此組內(nèi)的所有數(shù)據(jù)，網(wǎng)絡(luò)中的交換機和路由器只向有需求者復(fù)制并轉(zhuǎn)發(fā)其所需數(shù)據(jù)。主機可以向路由器請求加入或退出某個組，網(wǎng)絡(luò)中的路由器和交換機有選擇的復(fù)制并傳輸數(shù)據(jù)，即只將組內(nèi)數(shù)據(jù)傳輸給那些加

25、入組的主機。這樣既能一次將數(shù)據(jù)傳輸給多個有需要（加入組）的主機，又能保證不影響其他不需要（未加入組）的主機的其他通訊。組播的優(yōu)點：1. 需要相同數(shù)據(jù)流的客戶端加入相同的組共享一條數(shù)據(jù)流，節(jié)省了服務(wù)器的負(fù)載。具備廣播所具備的優(yōu)點。2. 由于組播協(xié)議是根據(jù)接受者的需要對數(shù)據(jù)流進行復(fù)制轉(zhuǎn)發(fā)，所以服務(wù)端的服務(wù)總帶寬不受客戶接入端帶寬的限制。3. 此協(xié)議和單播協(xié)議一樣允許在Internet寬帶網(wǎng)上傳輸。組播的缺點：1與單播協(xié)議相比沒有糾錯機制，發(fā)生丟包錯包后難以彌補，但可以通過一定的容錯機制和QOS加以彌補。2現(xiàn)行網(wǎng)絡(luò)雖然都支持組播的傳輸，但在客戶認(rèn)證、QOS等方面還需要完

26、善，這些缺點在理論上都有成熟的解決方案，只是需要逐步推廣應(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ù)實時檢測的用戶的帶寬和CPU使用率，調(diào)整視頻流的質(zhì)量。這需要使用一種可以將單一視頻源輸出為多碼率的編碼器。播放器客戶端依賴可用資源在不同碼率的流之間切換。"結(jié)果就是：更少緩存、更快的開始播放、為低端和高端鏈

27、接都提供良好的體驗。根據(jù)當(dāng)前廣泛使用的實現(xiàn)，更具體來說，自適應(yīng)串流（ABS）：使用 HTTP 傳送視頻流；使用多碼率編碼源內(nèi)容；每個單碼率的流被切成小的，幾秒鐘的小切片；流媒體客戶端首先獲取所有碼率的切片索引信息。一開始，客戶端先請求最低碼率的串流。如果客戶端判斷下載速度比當(dāng)前碼率的切片串流快，它就去請求下一個更高碼率的串流。隨著播放的進行，如果客戶端發(fā)現(xiàn)下載速度比當(dāng)前碼率的切片串流慢，轉(zhuǎn)而請求下一個較低碼率的串流。切片大小和具體實現(xiàn)密切相關(guān)，不過一般都在210秒之間。每個切片由一個完整的GOP序列組成，一個GOP序列里面有1個或者多個I幀，GOP序列的第一個幀必須是I幀，

28、并且每個切片都能單獨的解碼播放顯示。與傳統(tǒng)的流媒體技術(shù)比較，缺點：需要額外的存儲，更多的編碼代價，復(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月成

29、為國際標(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ò)?？捎玫?#160;MPEG-DASH 實現(xiàn)有：bitmovin GmbH 的開源 DASH 客戶端

30、庫 libdash 和 DASHEncoder Adobe HDS (HTTP Dynamic Streaming)Flash Player 和 Flash Media Server 的最新版支持傳統(tǒng)的 RTMP 協(xié)議和 HTTP協(xié)議。后者和Apple和微軟基于HTTP的方案類似?；贖TTP的流的優(yōu)勢是：不需要防火墻開普通web瀏覽器所需端口以外的任何端口允許視頻切片在瀏覽器、網(wǎng)關(guān)和CDN的緩存，從而顯著降低源服務(wù)器的負(fù)載。HDS 的文件格式為 FLV/F4V/MP4，索引

31、文件為 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 串流使用擴展名為 .m3u8 的文件作為索引，文件切片格式為TS，支持直播和時移。支持的客戶端包括 iPad, iPhone, STB，VLC和其他支持的設(shè)備。 Microsoft MSS (Microsoft Smooth Streaming)Smooth Streaming 是IIS的媒體服務(wù)擴展，用于支持基于HTTP的自適應(yīng)串流。在2010年11月發(fā)布的 IIS Media Services 4.0 中，微軟引入了一項使 Live Smooth Streaming H.264/AAC 視頻動態(tài)封裝成 Apple HLS 格式的功能，直接提供給 iOS 設(shè)備，而不需要再次編碼。同時支持直播和點播把1080P全高清視頻發(fā)送到Silverlight客戶端。