網易視頻云流媒體服務器原理和架構解析

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

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

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

4、流式）。     順序流媒體不可用于實況直播，僅能傳輸完整的音視頻文件（HTTP漸進式）。 區(qū)別實時流順序流音視頻數(shù)據(jù)源實時從錄制設備上采集，或（使用專用協(xié)議傳輸?shù)模┪募刹シ诺囊粢曨l文件服務器類型專用流媒體服務器，如：QuickTime Streaming ServerReal ServerWindows Media ServerFlash Media Server普通的HTTP服務器，或FTP服務器傳輸協(xié)議專用協(xié)議RTSP，HLS或RTMP等一般的HTTP協(xié)議，與傳輸網頁的協(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類產品的瀏覽器支持HTML5的瀏覽器蘋果的Safari瀏覽器支持HTML5的瀏覽器播放器視頻格式要求FLV， F

6、4VMP4無服務器要求專用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é)議。他的原理是先下載文件的基本信息，音頻視頻的時

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

8、nter）, 用于實況直播，將MPEG-2流分割為多個小片段后輸出；其三：文件分段器（file segmenter）, 用于文件點播，將文件分隔為多個小片段后輸出；分發(fā)原理數(shù)據(jù)經以上三部分處理后為.ts文件（媒體數(shù)據(jù)）及.m3u8文件（媒體數(shù)據(jù)索引）存在于服務器之上。 客戶端訪問.m3u8后按索引下載.ts文件進行播放。 下面為某m3u8文件內容：#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文件，存儲于普通服務器上。2. 蘋果應用程序或蘋果瀏覽器可以通過訪問.m3u8文件獲取到索引，并下載所需要的數(shù)據(jù)片段來播放。     HLS的實況直播1.  使用蘋果開發(fā)工具“流分段器”將基于H264、AAC、MP3的MPEG2傳輸流分段，可使用其它工具將MPEG4音視頻文件加載到MPEG2傳輸流當中。生成.ts和.m3u8文件，存儲于普通服務器上。2. 

10、 蘋果應用程序或蘋果瀏覽器可以通過訪問.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)  &

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ù)。一個單一的連接可以通過不同的通道傳輸多路網絡流，這些通道中的包都是按照固定大小的包傳輸?shù)?。必須采用Flash服務器FMS(Flash Media Server) 或

12、60;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é)議用

13、于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充當多媒體服務器的網絡遠程控制。RTSP連接沒有綁定到傳輸層連接，如TCP。在R

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

15、到現(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ā)送。在連接生命期，單個媒體流可通過

16、不同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請求，服務器連接產生連接標識。RTSP為純粹的傳輸控制協(xié)議。RTSP協(xié)議本身不與它負載的媒體數(shù)據(jù)相關。RTSP協(xié)議需要自定

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

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

19、數(shù)據(jù)傳輸。它提供對流媒體的類似VCR（Video Cassette Recorder）的控制功能，如播放、暫停、快進、錄制等，也就是RTSP對多媒體服務器實施網絡遠程控制。 流媒體服務器的功能框圖，如圖2所示。當服務器收到RTSP請求，它首先產生RTSP請求對象。服務器通過RTSP協(xié)議的應答信息將請求的內容以流會話（streaming session）的形式描述，內容包括數(shù)據(jù)流包含多少個流、媒體類型、和編解碼格式。一個流會話由一個或多個數(shù)據(jù)流組成，如視頻流和音頻流等。實際的數(shù)據(jù)流通過RTP協(xié)議傳遞到客戶端。RTP在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現(xiàn)流同步。RT

20、P本身并不能為順序傳送數(shù)據(jù)包提供可靠的傳送機制，它依靠RTCP一起提供流量控制和擁塞控制服務。在RTP會話期間，各連接者監(jiān)視下層網絡的性能，并將相關信息放入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

21、的端口獲得的，流媒體數(shù)據(jù)也都是打成RTP包，通過UDP端口發(fā)出去的，因此，對于TCP，UDP端口事件的調度以及如何把大量的流媒體數(shù)據(jù)從磁盤空間傳遞到網絡上成為制約流媒體服務器性能的主要因素。 傳統(tǒng)流媒體服務器的處理流程，如圖3所示。 流媒體服務器面對一個單一的客戶，完成的過程如下： 1）在客戶端發(fā)出RTSP連接請求后，服務器通過對TCP端口的監(jiān)聽，讀入請求。 2）解析請求內容，調入相應的流媒體文件。 3）形成RTP包，分發(fā)數(shù)據(jù)流包，獲得RTCP包。4）數(shù)據(jù)包發(fā)送完畢，關閉連接。  上圖是RTSP直播服務器的系統(tǒng)框圖。從攝像頭

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

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

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

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

26、善，這些缺點在理論上都有成熟的解決方案，只是需要逐步推廣應用到現(xiàn)存網絡當中。 自適性串流技術自適性串流（ABS - adaptive bitrate streaming），是一種在電腦網絡使用的一種串流技術。過去的流媒體技術多使用 RTP/RTSP，但現(xiàn)在的技術則大多基于 HTTP，并為更高效在大型分布式HTTP網絡（例如互聯(lián)網）分發(fā)而設計。此技術根據(jù)實時檢測的用戶的帶寬和CPU使用率，調整視頻流的質量。這需要使用一種可以將單一視頻源輸出為多碼率的編碼器。播放器客戶端依賴可用資源在不同碼率的流之間切換。"結果就是：更少緩存、更快的開始播放、為低端和高端鏈

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

28、并且每個切片都能單獨的解碼播放顯示。與傳統(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月成

29、為國際標準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（采用特別的編碼和操作模式），用于無線網絡?？捎玫?#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瀏覽器所需端口以外的任何端口允許視頻切片在瀏覽器、網關和CDN的緩存，從而顯著降低源服務器的負載。HDS 的文件格式為 FLV/F4V/MP4，索引

31、文件為 f4m，同時支持直播和時移。 Apple HLS (HTTP Live Streaming)是一種基于HTTP的媒體流通信協(xié)議，在 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月發(fā)布的 IIS Media Services 4.0 中，微軟引入了一項使 Live Smooth Streaming H.264/AAC 視頻動態(tài)封裝成 Apple HLS 格式的功能，直接提供給 iOS 設備，而不需要再次編碼。同時支持直播和點播把1080P全高清視頻發(fā)送到Silverlight客戶端。