音視訊通訊——直播協議和視訊推流

圖鴨科技發表於2018-03-15

近年來直播已成為網際網路行業的大熱話題,直播答題、遊戲直播、競賽直播等層出不窮,直播早已成為人們耳熟能詳的技術。事實上直播的興起不僅與新時代人們要求為自己代言的心理有關,同時也得益於頻寬的提速和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一行命令推流,再用播放器播放也就完成了。但是如果想要商業化,滿足使用者的多種需求,如回聲抑制、連麥直播、美顏濾鏡等,問題的複雜度就呈指數倍上漲了。

相關文章