摘要：本文作為直播介紹系列文的第篇，主要和大家談?wù)勚辈f(xié)議視頻推流等技術(shù)內(nèi)容直播協(xié)議流媒體分為直播和點(diǎn)播。使用語言編寫，支持多種協(xié)議相關(guān)網(wǎng)絡(luò)協(xié)議和移動(dòng)設(shè)備的流媒體服務(wù)器。

近年來直播已成為互聯(lián)網(wǎng)行業(yè)的大熱話題，直播答題、游戲直播、競賽直播等層出不窮，直播早已成為人們耳熟能詳?shù)募夹g(shù)。事實(shí)上直播的興起不僅與新時(shí)代人們要求為自己代言的心理有關(guān)，同時(shí)也得益于帶寬的提速和CDN技術(shù)的發(fā)展。伴隨著CDN技術(shù)的成熟，企業(yè)自己部署云服務(wù)器做直播也越來越簡單。

本文作為直播介紹系列文的第2篇，主要和大家談?wù)?strong>直播協(xié)議、視頻推流等技術(shù)內(nèi)容

流媒體分為直播和點(diǎn)播。通常來說點(diǎn)播使用的都是HTTP協(xié)議，直播主要用的是RTMP, HLS, HTTP-FLV等。近年來直播協(xié)議也有新發(fā)展如DASH，但仍處于起步階段。

直播和點(diǎn)播協(xié)議的不同，根源在于他們的業(yè)務(wù)差異。點(diǎn)播，常見用于優(yōu)酷，愛奇藝等視頻網(wǎng)站中電視劇、電影等媒體資源的播放，即點(diǎn)播都是錄制好的視頻，一千個(gè)人看同一個(gè)視頻，無論任何時(shí)候點(diǎn)進(jìn)去獲取到的媒體數(shù)據(jù)都是一樣的，而直播則不然，不同時(shí)候點(diǎn)進(jìn)來觀看到的信息是不一樣的。

通常來講，直播和點(diǎn)播是相互并不交融的，不過近些年來也有人創(chuàng)新發(fā)展——直播時(shí)移模式，即點(diǎn)播與直播相結(jié)合。其做法是將直播流錄制成一小片一小片的點(diǎn)播文件，然后用戶可以在任何地點(diǎn)、任意終端訪問任意內(nèi)容。比如你正在看一場球賽的直播，然后有一個(gè)鏡頭很精彩，想馬上再看一遍，就可以拖一下進(jìn)度條回退然后回放，在看完回放后還可以一鍵返回直播。

目前直播分發(fā)主要有以下特點(diǎn)：

1，flv居多，ts較少，原因主要是ts標(biāo)準(zhǔn)太過于復(fù)雜。Flv的標(biāo)準(zhǔn)開放文檔是11頁，ts的有174頁。對(duì)于一般的直播，flv基本能滿足需求，因此ts應(yīng)用就較少。當(dāng)然了，我們也可以借助于FFmpeg，但是它會(huì)將流媒體方面你想得到的和想不到的都封裝了，不夠精準(zhǔn)。

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

3，實(shí)時(shí)流一般使用rtmp。rtmp能做到1到3秒的延遲，是直播里除了rtsp外延遲最低的協(xié)議。PC上支持直接播放，移動(dòng)端可以用FFmpeg解碼播放。除了rtmp還有其他協(xié)議適合實(shí)時(shí)流媒體播放嗎？

實(shí)際上http-flv比rtmp更合適實(shí)時(shí)流播放。二者延遲一樣，在PC端上都可直接播，移動(dòng)端需要使用ffmpeg，但http-flv還有個(gè)好處就是能穿墻。但大多數(shù)CDN并不支持http-flv直播，因?yàn)橐话愕腤eb服務(wù)器不支持http-flv，這是個(gè)流媒體問題。

直播中流媒體數(shù)據(jù)的傳輸主要依賴服務(wù)器。目前開源的流媒體服務(wù)器，有RED5、CRTMPD、NGINX-RTMP和SRS等。

RED5：最古老的基于flash的流媒體服務(wù)的開源流媒體服務(wù)器。它由Java語言編寫，使用rtmp作為流媒體傳輸協(xié)議，與FMS完全兼容；具有流化flv、MP3文件，實(shí)時(shí)錄制客戶端流為flv文件，共享對(duì)象，實(shí)時(shí)視頻播放、Remoting等功能。但由于其技術(shù)較為落后，新入場的直播平臺(tái)都已放棄使用。

CRTMPD：使用c++語言編寫，支持多種rtmp協(xié)議、IPTV相關(guān)網(wǎng)絡(luò)協(xié)議和移動(dòng)設(shè)備的流媒體服務(wù)器。使用單線程異步socket，在當(dāng)時(shí)處于領(lǐng)先水平，但是當(dāng)NGINX出現(xiàn)后就漸漸淡出大眾視野了。

NGINX-RTMP ：基于NGINX模塊，使用C語言編寫的流媒體服務(wù)器，也是目前市場上使用最多的流媒體服務(wù)器。伴隨著2012年CDN業(yè)務(wù)的擴(kuò)展，直播業(yè)務(wù)需求暴漲，由于NGINX-RTMP中直播點(diǎn)播共用一套服務(wù)器，且用戶熟悉信任NGINX；NGINX-RTMP逐漸處于行業(yè)壟斷地位。

SRS（Simple Rtmp Sever）是一個(gè)國產(chǎn)的流媒體服務(wù)器，產(chǎn)品定位是運(yùn)營級(jí)的互聯(lián)網(wǎng)直播服務(wù)器集群，追求更好的概念完整性和最簡單實(shí)現(xiàn)的代碼。據(jù)官網(wǎng)介紹其效率非常高，能達(dá)到NGINX-RTMP的3倍，而且中英文文檔各有一份，較為適合國內(nèi)程序員的開發(fā)環(huán)境。

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

如上圖所示，直播中通常在從攝像頭和麥克風(fēng)等采集到相關(guān)數(shù)據(jù)源后需要做一些封裝前處理，如去噪、美顏、變聲等，然后進(jìn)行音視頻編碼，再用相適應(yīng)的流媒體協(xié)議封裝，進(jìn)行碼率自適應(yīng)后就可投到相關(guān)站點(diǎn)展示了。

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

如果你是iOS或者Android程序員，做RTMP推流就會(huì)更簡單，可以直接找一個(gè)推流的數(shù)據(jù)庫然后給出視頻參數(shù)，以及最終的RTMP地址，就能推出一個(gè)標(biāo)準(zhǔn)的RTMP流

如果你是C++程序員，會(huì)麻煩很多，你至少要掌握采集、編碼、寫流這3個(gè)步驟。當(dāng)然，這些步驟都有庫可以調(diào)用，但是即便如此，假設(shè)你使用FFmpeg庫，完成上述動(dòng)作代碼也需要100行左右了；因?yàn)槠渲饕拇a流程就需包括打開音視頻設(shè)備、創(chuàng)建編解碼器、設(shè)置編碼參數(shù)、初始化網(wǎng)絡(luò)流句柄、寫協(xié)議頭、循環(huán)采集數(shù)據(jù)、解碼數(shù)據(jù)、編碼數(shù)據(jù)、格式封裝和寫網(wǎng)絡(luò)流。

當(dāng)然，你可以直接用FFmpeg的命令行，一條命令完成推流，但是這也僅限于測試或者做簡單的demo，真正的工程環(huán)境中并不適用，因?yàn)檫@種一條簡單命令的方法在許多功能上都不能支持。

總之，做直播難易程度主要是和你想實(shí)現(xiàn)的功能有關(guān)，如果你只是打算自己做測試，那下載一個(gè)開源服務(wù)器代碼，編碼運(yùn)行，再用FFmpeg一行命令推流，再用播放器播放也就完成了。但是如果想要商業(yè)化，滿足用戶的多種需求，如回聲抑制、連麥直播、美顏濾鏡等，問題的復(fù)雜度就呈指數(shù)倍上漲了。