crtmpserver系列(一)：流媒體概述

概述

所謂流媒體按照字面意思理解就是像流同樣的媒體，看起來像是廢話。流媒體如今司空見慣，因此通常人大概不會有疑問。事實上在流媒體尚未出現的時候，基本上經過網絡播放電影就不太現實。經過網絡播放電影的時候必須先將整個文件下載到電腦上而後才能播放，因此通常都要緩衝好久，這也是爲何最開始迅雷等下載工具流行的緣由，其實大多數都是用來下電影了。

流媒體最大的特色便是可以作到邊下載邊播放，而不須要預先將整個文件所有下載完成以後才能播放，這樣極大的改善了用戶體驗，也提升了實時性，使得網絡直播成爲可能。

那麼流媒體是如何作到邊下載邊播放的呢，咱們要了解流媒體系統的組成。

流媒體系統的組成

一個完整的流媒體系統由這些部分組成，信號採集，編碼，傳輸，解碼，輸出。

信號採集：咱們所說的流媒體系統都是要在計算機系統上面進行處理的，而系統中最主要的元素是音頻和視頻，從物理上面來講音頻其實是一種經過物理震動造成的機械波，音頻採集便是將這種物理波轉換爲電信號進而轉換成二進制的音頻數據，通常採集獲得的原始音頻數據是PCM數據。視頻是什麼，視頻其實是順序呈現出來的一幅幅連續的靜止圖像，因此視頻其實是由一幅幅靜止的圖像組成，視頻的採集就是接二連三的採集這些靜止的圖像的過程，這些一幅幅的圖像通常被稱爲幀。那麼這些被稱爲幀的靜止圖像又是怎麼被採集的呢，實際上圖像的表現形式並非像聲音同樣的波，初中的物理咱們就學過成像，咱們之因此可以看到圖像，是由於照射在物體上的光反射到咱們的眼睛進入視網膜，傳導到視神經最後被咱們大腦感知。因此圖像的採集是對光信號的採集與轉換，將光信號轉換爲二進制的圖像幀的過程，通常咱們獲得的原始圖像數據格式是YUV格式。

編碼：什麼是編碼，爲何要編碼。假設咱們的網絡容量是無限的，傳輸速度也是無限大的，這固然是不須要編碼的。而實際上並非，咱們採集到的原始音視頻數據量是很大的，因此咱們須要想辦法，將採集到的原始的音視頻二進制數據量儘可能變小，方便在網絡上進行傳輸，同時又須要在還原(解碼)的時候儘可能接近原始音視頻(損失，編碼也有分爲有損和無損)。咱們有時候稱編碼也叫壓縮編碼，其實壓縮這個概念相似咱們平時的壓縮文件的原理同樣，舉個簡單的例子，例若有一個文本文件其內容是00000000000000000000000000000000000000000000000000 這麼一串字符串，實際就是50個0字符，咱們徹底能夠用最簡單的描述來壓縮，例如咱們壓縮以後文件內容變成50’0’表示這裏有50個0字符。在還原的時候這裏直接用50個0字符填充便可，這樣是否是會節約大量的空間呢，若是不是50個0而是一萬個0字符呢，這樣通過壓縮以後的壓縮比會更大，也就是說重複的冗餘數據越多，壓縮效率越高。固然實際的壓縮算法確定沒這麼簡單，說這麼個簡單的例子只是爲了說明原理而已。視頻的編碼算法有不少種，並且要複雜不少，每一種算法的運行效率，壓縮比，損失率都不同。而原理都是同樣的，在最多見的概念中，有幀內壓縮和幀間壓縮。

什麼是幀內壓縮呢，假設一副圖像的背景是純紅色，前面站我的(拍證件照的場景)。在編碼的時候一副圖像被分紅不少小塊(宏塊)，這樣因爲背景中會有不少相鄰的小塊都是純紅色，不少純紅色的小塊均可以根據其周圍的小塊推斷出來，而不須要單獨編碼，這就是幀內壓縮，這種壓縮是在一個幀內部進行的，跟其先後的圖像沒有關係。

那麼幀間壓縮又是什麼，若是一個視頻中相鄰的2副圖像，背景都是純紅色，背景中有一個球在圖像1中的位置是A點。在圖像2中的位置是B點。實際上若是把圖像1和圖像2疊在一塊兒會發現他們除了球的位置不同以外，其餘的部分是同樣的，也就是說這兩幅相鄰的圖像有很大一部分是相同的。在編碼第2副圖像的時候徹底能夠只編碼其與上一副圖像的不一樣部分。若是圖像1咱們須要徹底編碼，圖像1被稱爲關鍵幀(通常稱爲I幀)，而圖像2在還原的時候須要參考圖像1，因此稱爲參考幀(通常稱爲P幀)。若是沒有關鍵幀，那麼參考幀是沒法還原的。固然在編碼的時候，一幀不只能夠參考其上一幀，還能夠參考其下一幀(雙向預測的幀間壓縮)，例如一個球從左滾到右，這種運動是能夠作預測的。這種當前幀的編碼參考其相鄰圖像的算法就是幀間壓縮算法。

傳輸：通過採集，編碼咱們如今已經得到了音視頻數據幀，可是通常觀看視頻的必定不是在採集編碼的現場，不然就不須要傳輸了，傳輸的過程就是將編碼後的音視頻數據經過網絡(互聯網，或者有線電視網等，咱們只討論互聯網)傳輸到但願觀看的觀衆那裏。數據從一個地方傳遞到另外一個地方這個過程就是傳輸。傳輸過程當中最重要的固然是流媒體協議了，爲何還須要流媒體協議？在流媒體播放的時候會有一些播放邏輯，例如，播放，暫停，跳轉，中止，快進，快退。另外在編碼以後的數據從一端傳遞到另外一端，另外一端須要將編碼以後的數據還原成編碼以前的原始數據才能播放。如何還原？必須得知道以前編碼是使用什麼算法編碼的，在還原的時候才能採用相應的解碼算法進行還原。那麼編碼的時候使用的是什麼算法，這個也須要從一端通知到另外一端，這個信息也是在流媒體傳輸協議中會有的。除此以外還會有其餘的一些邏輯信息，例如視頻的幀率，關鍵幀的間隔(GOP Size)等。總結爲一句話，編碼事後的音視頻數據經過網絡從一端傳遞到另外一端，在另外一端對數據還原的時候須要一些信息，而且須要支持一些播放場景的邏輯，這些都須要在流媒體協議中進行描述。目前最流行的流媒體協議，Adobe公司的RTMP，RTSP，微軟的MMS等。

解碼：通過編碼壓縮的數據必須還原成編碼以前的原始數據才能播放顯示，這個還原過程就是解碼的過程。

輸出：輸出的過程就是播放出來的過程，與採集的時候同樣，實際上這是將採集的原始音視頻數據通過模數轉換轉換成物理信號，視頻信號經過顯示器顯示出來，音頻信號經過音箱放出來。

媒體文件封裝

咱們以前討論的是媒體的流式播放，其實這個流式主要是指傳輸是流動的，並且視頻幀能夠邊傳輸，邊解碼播放。若是咱們但願將播放的內容保存到磁盤上，就必需要有一種文件格式來組織這些數據，以必定的結構來保存這些音視頻數據。爲何不直接將網絡傳輸過來的內容直接寫到一個文件中保存呢，若是直接將全部傳輸過來的數據不加任何結構組織直接保存的話，那麼在播放的時候如何播放？如何知道這些二進制數據哪些是音頻哪些是視頻，如何知道每一幀音視頻數據在文件中的邊界，如何知道該音視頻的內容是經過什麼編碼算法編碼的，如何知道播放一幀數據以後再隔多長時間播放下一幀數據，若是像有的電影文件須要多種字幕又如何組織。因此這就必需要有一種文件格式可以組織這些音視頻數據而且附加這些播放必須的信息在文件中。這就是媒體文件的封裝。現存有不少種媒體文件，有的是某個公司的專利，有的是國際標準，例如MP4，MP3，AVI，RMVB等等等等。因此若是要保存這些流媒體數據到文件中，則必須經過必定的文件封裝格式將這些音視頻數據保存在具備必定格式的媒體文件中。

傳輸協議

目前使用的最多的流媒體傳輸協議固然是RTMP和RTSP了。微軟的MMS基本在工做中接觸的很少，特別是當前比較火爆的互聯網直播。還有一個須要特別提到的HTML5出來以後，不少之前經過flash客戶端承載RTMP協議的播放方式被以HLS替換了。可是實時性要求比較高的直播仍是須要經過RTMP或者RTSP協議。HLS嚴格來講，其實我感受都不能叫流媒體協議，HLS實際上基本能夠認爲是一個TS文件的播放列表，沒有流媒體協議中的那些邏輯功能，播放，暫停，中止。應該說HLS僅僅是特定狀況下出來的，主要是針對跨平臺的瀏覽器進行直播。咱們所看到的HLS大部分都是經過移動設備，PC機器上的瀏覽器來播放的。

須要指出的是，在與蘋果的HLS爭奪市場的過程當中，同時出現了多種相似的技術，都是用的HTTP協議，通常咱們稱爲HTTP漸進式下載。例如微軟的Live Smooth Streaming 中文名稱爲直播平滑流，這種技術須要微軟IIS7及以上版本的web服務器和Silverlight客戶端支持。另一種是開源的技術好像並非某個公司出品，叫Http Pseudo-Streaming 中文名是僞流。目前只看到一個基於Apache服務器的插件H264 Streaming Module for Apache，客戶端貌似也是使用Flash Player。還有一種叫HTTP Dynamic Streaming 中文稱作HTTP動態流，是Adobe公司的技術方案，其服務端須要Flash Media Server支持，客戶端則是Flash Player。其實如今的Flash Media Server 也已經支持HLS了。蘋果的HLS就不說了如今不少服務器以及開源代碼都支持HLS，客戶端呢只要支持HTML5的瀏覽器基本也都支持HLS，如今的HLS已是主流。最後要說的是新出現的一種技術標準，MPEG-DASH目的爲了統一這些技術方案，還在標準化中，若是真的標準化，也有可能取代HLS，畢竟HLS尚未稱爲正式標準，只是蘋果公司提交了個草案。

RTMP協議的發展得益於flash播放器的普遍傳播，而RTSP協議則得益於其協議的開源。本系列要講解的crtmpserver就是基於RTMP協議的開源流媒體服務器，開發語言爲C++。等同的產品還有Red5 語言爲Java也是開源。另一個比較有影響力是wowza屬於閉源產品。此外RTMPDump項目是用的比較多的RTMP客戶端開源項目，其中的librtmp庫使用的很普遍，C語言編寫。另外OpenRTMFP是基於p2p技術的RTMP。