直播平臺搭建中音視訊通訊——直播協定和視訊推流

近年來直播已成爲網際網路行業的大熱話題，直播答題、遊戲直播、競賽直播等層出不窮，直播早已成爲人們耳熟能詳的技術。事實上直播的興起不僅與新時代人們要求爲自己代言的心理有關，同時也得益於頻寬的提速和CDN技術的發展。伴隨着CDN技術的成熟，企業自己部署雲伺服器做直播也越來越簡單。

 本文作爲直播介紹系列文的第2篇，主要和大家談談直播平臺搭建中音視訊通訊——直播協定和視訊推流

 直播協定

 串流媒體分爲直播和點播。通常來說點播使用的都是HTTP協定，直播主要用的是RTMP, HLS, HTTP-FLV等。近年來直播協定也有新發展如DASH，但仍處於起步階段。 直播和點播協定的不同，根源在於他們的業務差異。

 

點播，常見用於優酷，愛奇藝等視訊網站中電視劇、電影等媒體資源的播放，即點播都是錄製好的視訊，一千個人看同一個視訊，無論任何時候點進去獲取到的媒體數據都是一樣的，而直播則不然，不同時候點進來觀看到的資訊是不一樣的。

 

 通常來講，直播和點播是相互並不交融的，不過近些年來也有人創新發展——直播時移模式，即點播與直播相結合。其做法是將直播流錄製成一小片一小片的點播檔案，然後使用者可以在任何地點、任意終端存取任意內容。比如你正在看一場球賽的直播，然後有一個鏡頭很精彩，想馬上再看一遍，就可以拖一下進度條回退然後回放，在看完回放後還可以一鍵返回直播。

 

 目前直播分發主要有以下特點：  

1，flv居多，ts較少，原因主要是ts標準太過於複雜。Flv的標準開放文件是11頁，ts的有174頁。對於一般的直播，flv基本能滿足需求，因此ts應用就較少。當然了，我們也可以藉助於FFmpeg，但是它會將串流媒體方面你想得到的和想不到的都封裝了，不夠精準。

 

 2，rtmp和hls並存。一般來講，rtmp用在PC端上，使用flash播放；hls用作手機和平板上。

 

 3，實時流一般使用rtmp。rtmp能做到1到3秒的延遲，是直播裡除了rtsp外延遲最低的協定。PC上支援直接播放，行動端可以用FFmpeg解碼播放。除了rtmp還有其他協定適合實時串流媒體播放嗎？  

實際上http-flv比rtmp更合適實時流播放。二者延遲一樣，在PC端上都可直接播，行動端需要使用ffmpeg，但http-flv還有個好處就是能穿牆。但大多數CDN並不支援http-flv直播，因爲一般的Web伺服器不支援http-flv，這是個串流媒體問題。

 

 直播伺服器 

直播中串流媒體數據的傳輸主要依賴伺服器。目前開源的串流媒體伺服器，有RED5、CRTMPD、NGINX-RTMP和SRS等。

 

 RED5：最古老的基於flash的串流媒體服務的開源串流媒體伺服器。它由Java語言編寫，使用rtmp作爲串流媒體傳輸協定，與FMS完全相容；具有流化flv、MP3檔案，實時錄製用戶端流爲flv檔案，共用物件，實時視訊播放、Remoting等功能。但由於其技術較爲落後，新入場的直播平臺都已放棄使用。 

 

CRTMPD：使用c++語言編寫，支援多種rtmp協定、IPTV相關網路協定和移動裝置的串流媒體伺服器。使用單執行緒非同步socket，在當時處於領先水平，但是當NGINX出現後就漸漸淡出大衆視野了。 

 

NGINX-RTMP ：基於NGINX模組，使用C語言編寫的串流媒體伺服器，也是目前市場上使用最多的串流媒體伺服器。伴隨着2012年CDN業務的擴充套件，直播業務需求暴漲，由於NGINX-RTMP中直播點播共用一套伺服器，且使用者熟悉信任NGINX；NGINX-RTMP逐漸處於行業壟斷地位。 

 

SRS（Simple Rtmp Sever）是一個國產的串流媒體伺服器，產品定位是運營級的網際網路直播伺服器叢集，追求更好的概唸完整性和最簡單實現的程式碼。據官網介紹其效率非常高，能達到NGINX-RTMP的3倍，而且中英文文件各有一份，較爲適合國內程式設計師的開發環境。

 

 直播推流 

 

直播推流的總體過程如下圖

 

 

如上圖所示，直播中通常在從攝像頭和麥克風等採集到相關數據源後需要做一些封裝前處理，如去噪、美顏、變聲等，然後進行音視訊編碼，再用相適應的串流媒體協定封裝，進行位元速率自適應後就可投到相關站點展示了。

 

 

 

 

但是在不同的技術語言下做直播推流的方法也是不同的：

 

如果你是iOS或者Android程式設計師，做RTMP推流就會更簡單，可以直接找一個推流的數據庫然後給出視訊參數，以及最終的RTMP地址，就能推出一個標準的RTMP流  

 

如果你是C++程式設計師，會麻煩很多，你至少要掌握採集、編碼、寫流這3個步驟。當然，這些步驟都有庫可以呼叫，但是即便如此，假設你使用FFmpeg庫，完成上述動作程式碼也需要100行左右了；因爲其主要的程式碼流程就需包括開啓音視訊裝置、建立編解碼器、設定編碼參數、初始化網路流控制代碼、寫協定頭、回圈採集數據、解碼數據、編碼數據、格式封裝和寫網路流。

 

 當然，你可以直接用FFmpeg的命令列，一條命令完成推流，但是這也僅限於測試或者做簡單的demo，真正的工程環境中並不適用，因爲這種一條簡單命令的方法在許多功能上都不能支援。 

 

 總結：

 

 總之，做直播難易程度主要是和你想實現的功能有關，如果你只是打算自己做測試，那下載一個開源伺服器程式碼，編碼執行，再用FFmpeg一行命令推流，再用播放器播放也就完成了。但是如果想要商業化，滿足使用者的多種需求，如回聲抑制、連麥直播、美顏濾鏡等，問題的複雜度就呈指數倍上漲了。