快速搭建移動直播系統的方法？

01-08

求賜教

一、直播的技術架構：

直播視頻採集SDK（PC/IOS/Anddroid）——直播CDN

（直播流分發加速）——直播視頻播放器SDK（PC/IOS/Android）

二、音視頻處理的一般流程：

數據採集→數據編碼→數據傳輸(流媒體伺服器) →解碼數據→播放顯示

1、數據採集：

攝像機及拾音器收集視頻及音頻數據，此時得到的為原始數據

涉及技術或協議：

攝像機：CCD、CMOS

拾音器：聲電轉換裝置（咪頭）、音頻放大電路

2、數據編碼：

使用相關硬體或軟體對音視頻原始數據進行編碼處理（數字化）及加工（如音視頻混合、打包封裝等），得到可用的音視頻數據

涉及技術或協議：

編碼方式：CBR、VBR

編碼格式

視頻：H.265、H.264、MPEG-4等，封裝容器有TS、MKV、AVI、MP4等

音頻：G.711μ、AAC、Opus等，封裝有MP3、OGG、AAC等

3、數據傳輸：

將編碼完成後的音視頻數據進行傳輸，早期的音視頻通過同軸電纜之類的線纜進行傳輸，IP網路發展後，使用IP網路優傳輸

涉及技術或協議：

傳輸協議：RTP與RTCP、RTSP、RTMP、HTTP、HLS（HTTP Live

Streaming）等

控制信令：SIP和SDP、SNMP等

4、解碼數據：

使用相關硬體或軟體對接收到的編碼後的音視頻數據進行解碼，得到可以直接顯示的圖像/聲音

涉及技術或協議：

一般對應的編碼器都會帶有相應的解碼器，也有一些第三方解碼插件等

5、播放顯示：

在顯示器（電視、監視屏等）或揚聲器（耳機、喇叭等）里，顯示相應的圖像畫面或聲音

涉及技術或協議：

顯示器、揚聲器、3D眼鏡等

三、常見的視頻直播相關協議：

1、RTMP(Real

Time Messaging Protocol，實時消息傳送協議)

RTMP是Adobe Systems公司為Flash播放器和伺服器之間音頻、視頻和數據傳輸開發的開放協議。它有三種變種：

1）、工作在TCP之上的明文協議，使用埠1935；

2）、RTMPT封裝在HTTP請求之中，可穿越防火牆；

3）、RTMPS類似RTMPT，但使用的是HTTPS連接；

RTMP協議是被Flash用於對象、視頻、音頻的傳輸。這個協議建立在TCP協議或者輪詢HTTP協議之上。RTMP協議就像一個用來裝數據包的容器，這些數據既可以是AMF格式的數據，也可以是FLV中的視音頻數據。一個單一的連接可以通過不同的通道傳輸多路網路流，這些通道中的包都是按照固定大小的包傳輸的。

2、RTSP(Real

Time Streaming Protocol，實時流傳輸協議)

RTSP定義了一對多應用程序如何有效地通過IP網路傳送多媒體數據。RTSP提供了一個可擴展框架，數據源可以包括實時數據與已有的存儲的數據。該協議目的在於控制多個數據發送連接，為選擇發送通道如UDP、組播UDP與TCP提供途徑，並為選擇基於RTP上發送機制提供方法。

RTSP語法和運作跟HTTP/1.1類似，但並不特彆強調時間同步，所以比較能容忍網路延遲。代理伺服器的緩存功能也同樣適用於RTSP，並且因為RTSP具有重新導向功能，可根據實際負載情況來切換提供服務的伺服器，以避免過大的負載集中於同一伺服器而造成延遲。

3、RTP(Real-time

Transport Protocol，實時傳輸協議)

RTP是針對多媒體數據流的一種傳輸層協議，詳細說明了在互聯網上傳遞音頻和視頻的標準數據包格式。RTP協議常用於流媒體系統（配合RTCP協議），視頻會議和一鍵通系統（配合H.323或SIP），使它成為IP電話產業的技術基礎。

RTP是建立在UDP協議上的，常與RTCP一起使用，其本身並沒有提供按時發送機制或其它服務質量（QoS）保證，它依賴於低層服務去實現這一過程。

RTP 並不保證傳送或防止無序傳送，也不確定底層網路的可靠性，只管發送，不管傳輸是否丟包，也不管接收方是否有收到包。RTP 實行有序傳送，RTP中的序列號允許接收方重組發送方的包序列，同時序列號也能用於決定適當的包位置，如在視頻解碼中，就不需要順序解碼。

4、RTCP(Real-time

Transport Control Protocol，實時傳輸控制協議）

RTCP是RTP的配套協議，為RTP媒體流提供信道外的控制。RTCP和RTP一起協作將多媒體數據打包和發送，定期在多媒體流會話參與者之間傳輸控制數據。

RTCP的主要功能是為RTP所提供的服務質量（QoS）提供反饋，收集相關媒體連接的統計信息，例如傳輸位元組數，傳輸分組數，丟失分組數，單向和雙向網路延遲等等。網路應用程序可以利用RTCP所提供的信息來提高服務質量，比如限制流量或改用壓縮比小的編解碼器。

四、利益相關

我們團隊是做直播技術的，底層架構都是做好的，開放給開發者sdk和api介面，開發者接入後就可以實現直播的功能。歡迎相互交流學習。我的qq3103607948

直播技術要求這塊上面已經講的很詳細了，我就不再贅述了。作為又拍直播雲的研發，這邊就說說接入又拍直播雲（直播雲 - 一站式視頻直播加速）的流程，非常的簡單方便。新用戶通過官網註冊賬號，並進行個人/公司認證，審核通過後可以正常使用控制台。詳細步驟如下所述：

創建服務：

Step1，創建服務。進入又拍雲官網——控制台——點擊【創建服務】。參考如下：

Step2. 配置服務.源站選擇及配置：

又拍雲源，用戶通過推流器或編碼器主動將直播流推送至又拍，經過又拍的流媒體加速中心加速後，通過相應的拉流 URL 進行訪問。適用場景為秀場主播、遊戲直播和在線教育等；

自主源站，客戶提供直播源伺服器，又拍向客戶源請求源數據。適用場景為電視台，體育比賽等。

又拍雲源配置：

推流域名：用於推送直播流的域名，長度小於60個字元，支持泛域名綁定，比如：*.yourdomain. com

播放域名：用於播放直播流的域名，默認支持 RTMP，HLS 和 HTTP-FLV；推流域名、播放域名共計最多可綁定個域名，支持泛域名，所綁定的域名需要備案；

接入點：支持1-60位英文字元和數字，如：rtmp://http://push.example.com/{接入點}/{流名}，該項可不填，為空時表示，可以使用任意的接入點。

示例：接入點：live；推流域名：http://push.example.com；播放域名：http://pull.example.com

則

推流地址：rtmp:// http://push.example.com /live/streamid

rtmp 播放地址：rtmp://http://pull.example.com/live/ streamid

hls 播放地址：http:// http://pull.example.com/live/ streamid.m3u8

flv 播放地址：http:// http://pull.example.com/live/ streamid.flv

自主源站，請填寫自己的源站地址

源站：支持 RTMP/HTTP 兩種協議回源，源站支持輸入域名/IP，請填寫正確的源站地址，直播流將推流到源站拉取直播流進行分發

播放域名：用於播放直播流的域名，默認支持 RTMP，HLS 和 HTTP-FLV，推流域名、播放域名共計最多可綁定 10 個域名，支持泛域名，所綁定的域名需要備案；

接入點：支持1-60位英文字元和數字，如：rtmp://http://push.example.com/{接入點}/{流名}，該項可不填，為空時表示，可以使用任意的接入點。

示例：接入點：live；協議為：RTMP；源站：11.11.11.11 ；埠為：1935

則

回源地址為：rtmp:// 11.11.11.11:1935/live/streamid

播放域名：http://pull.example.com

hls 播放地址：http:// http://pull.example.com/live/ streamid.m3u8

flv 播放地址：http:// http://pull.example.com/live/ streamid.flv

註：流名默認支持任意字元串

Step3. 配置成功

配置完成後，系統會自動為您生成該推流域名需要 CNAME 地址，您可以前往域名的 DNS 服務商為自主域名添加 CNAME 地址。

——————————分割線——————————

三步完成配置，就是這麼輕鬆簡單。

附上又拍直播雲文檔：http://docs.upyun.com/live/

移動直播行業的火熱會在很長一段時間內持續，通過和各行業的整合，從而成為具有無限可能性的行業。主要因為以下三個原因：

第一，移動直播的UGC生產模式比PC端的直播更明顯，人人都有設備，隨時隨地開播，完全順應了互聯網時代的開放性原則，能刺激更多人去創造和傳播優質內容。

第二，網路帶寬和速度在逐漸提高，網路成本在逐漸下降，為移動直播提供一個極佳的發展環境。文字、聲音、視頻、遊戲等都會在移動直播中呈現，創造出更加豐富的用戶體驗。直播可以以SDK的形式接入到自己的應用中，比如，教育領域中的課後輔導完全可以以直播的形式開展業務、電商也可藉助直播讓用戶挑選商品，促進銷售。

第三，一個與VR/AR技術相結合的移動直播為整個行業的未來提供了新的發展空間。VR/AR直播能夠讓用戶身臨其境，帶動主播與觀眾更貼切真實的互動，大大提高平台的用戶參與度。

當下，有技術實力和流量優勢的互聯網從業者都不願錯過直播這個風口，如何快速搭建一個直播系統成了大家關心的問題，我想和大家分享下我的經驗。我從事於一家直播產品開發商，我們的產品為了快速趕上市場，並沒有自己完全去自己做，而是使用了趣拍雲服務提供的直播SDK。

從業者都知道，一個完整直播產品應該包含以下環節：推流端（採集、前處理、編碼、推流），服務端處理（轉碼、錄製、截圖、鑒黃），播放器（拉流、解碼、渲染）、互動系統（聊天室、禮物系統、贊）。下面我就一一講述下直播SDK在各個環節所做的工作。

一、移動直播推流端需要做哪些工作？

直播推流端即主播端，主要通過手機攝像頭採集視頻數據和麥克風采集音頻數據，經過一系列前處理、編碼、封裝，然後推流到CDN進行分發。

1、採集

移動直播SDK通過手機攝像頭和麥克風直接採集音視頻數據。其中，視頻採樣數據一般採用RGB或YUV格式、音頻採樣數據一般採用PCM格式。採集到的原始音視頻的體積是非常大的，需要經過壓縮技術處理來提高傳輸效率。

2、前處理

在這個環節主要處理美顏、水印、模糊等效果。美顏功能幾乎是直播的標配功能。我們調研中發現太多case是因為沒有美顏功能被拋棄使用的。另外國家明確提出了，所有直播都必須打有水印並回放留存15天以上。

美顏實際上是通過演算法去識別圖像中的皮膚部分，對皮膚區域進行色值調整。通過顏色對比找到皮膚區域，可以進行色值調整、添加白色圖層或調整透明度等來等來達到美白效果。在美顏處理方面，最著名的GPUImage提供了豐富的效果，同時可以支持iOS和Android，支持自己寫演算法實現自己最理性的效果。GPUImage內置了120多種常見濾鏡效果，添加濾鏡只需要簡單調用幾行代碼就可以了。

3、編碼

為了便於手機視頻的推流、拉流以及存儲，通常採用視頻編碼壓縮技術來減少視頻的體積，現在比較常用的視頻編碼是H.264。在音頻方面，比較常用的是用AAC編碼格式，其它如MP3、WMA也是可選方案。視頻經過編碼壓縮大大提高了視頻的存儲和傳輸效率，當然，經過壓縮後的視頻在播放時必須進行解碼。

相較於之前的H.264，2012年誕生的H.265編解碼標準有了相當大的改善，做到了僅需要原來一半帶寬即可播放相同質量的視頻，低於1.5Mbps的網路也能傳輸1080p的高清視頻。像阿里雲、金山雲都在推自己的H.265編解碼技術，隨著直播的快速發展和對帶寬的依賴，H.265編解碼技術已有全面取代H.264的趨勢。

H264和H265個模塊技術差異：

另外，硬體編碼已經成為移動直播的首選方案，軟編碼處理在720p以上的視頻頹勢非常明顯。在iOS平台上硬體編碼的兼容性比較好，可以直接採用，但在 Android 平台上，MediaCodec 編碼器針對不同的晶元平台表現差異還是非常大的，要完全實現全平台兼容的成本還是非常高的。

4、推流

要想用於推流還必須把音視頻數據使用傳輸協議進行封裝，變成流數據。常用的流傳輸協議有RTSP、RTMP、HLS等，使用RTMP傳輸的延時通常在1–3秒，對於移動直播這種實時性要求非常高的場景，RTMP也成為移動直播中最常用的流傳輸協議。最後通過一定的Qos演算法將音視頻流數據推送到網路斷，通過CDN進行分發。在直播場景中，網路不穩定是非常常見的，這時就需要Qos來保證網路不穩情況下的用戶觀看直播的體驗，通常是通過主播端和播放端設置緩存，讓碼率均勻。另外，針對實時變化的網路狀況，動態碼率和幀率也是最常用的策略。

當然，在網路傳輸方面全部自己來做基本不現實，找提供推流服務的CDN服務商提供解決方案是最好的選擇，可參考文章開頭介紹的雲視頻服務商。據了解，阿里雲是國內唯一能自研CDN緩存伺服器的廠商，性能非常有保障。當然，大多數直播平台都會同時接入多個視頻雲服務提供商，這樣可以做拉流線路互備，對推流後視頻集群再進行優化也可提高直播的流暢性和穩定性。

二、服務端處理需要做哪些工作？

要想適配各終端和平台，服務端還需要對流進行轉碼，如支持RTMP、HLS、FLV等格式拉流，支持一路轉多路適配不同網路和解析度的終端設備。

1、截圖、錄製、水印

像阿里雲等雲服務商都提供了實時轉碼技術，將用戶推流碼率較高（比如720P）實時轉化成較低清晰度（比如360P）的流以適應播放端的需求。如果要自己搭建實時轉碼系統，這個成本是極高的，一台8核設備只能實時轉10路流，如果一個正常的直播平台有1000路流，就需要100台設備，加上後期的運維成本，一般公司就吃不消了。

2、鑒黃

2016年4月14日，文化部查出了鬥魚、虎牙、YY、熊貓TV、六間房、9158等涉嫌提供含宣揚淫穢、暴力、教唆犯罪的網路直播平台，被列入查處名單。政府介入管制有利於直播行業打造健康的生態，進入良性發展。這也意味著為了安全直播產品鑒黃成了必需環節，使用技術手段去鑒黃是移動直播平台必然採用的方案。

市面上提供鑒黃服務的方案主要有兩種，第一種是對視頻進行截圖，然後對圖片進行鑒黃，返回鑒黃結果和分值。典型的企業有阿里（綠網）、圖譜科技，他們目前都支持直接傳入視頻，經過服務端分析返回結果。通常由業務系統接入鑒黃服務，根據鑒黃結果對直播流進行控制，如切斷直播流、封禁賬號等。第二種是和CDN結合，直接對直播流進行分析，識別結果分為色情、疑似色情、性感和正常，業務系統根據識別結果直接控制直播流。典型的企業是Viscovery，這套方案的優點是實時性保證比較好，缺點是必須部署到CDN或自己的機房，使用成本相對高一些。

還有像趣拍雲服務這種一站式直播解決方案提供商，他們的做法是，用戶只需在控制台對鑒黃服務進行配置就可以針對每個應用、每一路直播流進行實時審核。在控制台中，趣拍視頻雲服務實時將鑒黃結果返回，用戶可以直接查看色情直播和違規界面的截圖，同時可以對直播流進行控制，切斷問題直播流。該服務商還提供了簡訊、郵件和站內信功能，避免漏掉任何一個非法視頻，給平台造成損失，我們就使用了這種方式。

三、播放器端需要做哪些工作？

在播放器端如何做到秒開，直播過程中保證畫面和聲音清晰度的同時，穩定、流程、無卡頓的直播流量，這些工作都需要播放器端配合服務端來做優化，做到精確調度。

1、拉流

拉流實際是推流的逆過程。首先通過播放端獲取碼流，標準的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的專利協議，開源軟體和開源庫都支持的比較好，如開源的librtmp庫，播放端只要支持flashPlayer的就能非常簡單的播放RTMP直播，直播延遲一般在1–3秒。HLS是蘋果提出的基於HTTP的流媒體傳輸協議，HTML5可以直接打開播放，通過微信、QQ等軟體分享出去，用戶也可以直接觀看直播，可以說移動直播app，HLS拉流協議是必須支持的，缺點是延遲通常大於10秒。FLV（HTTP-FLV）協議是使用HTTP協議傳輸流媒體內容的一個協議，也不用擔心被Adobe的專利綁架，直播延遲同樣可以做到1–3秒。

各拉流協議的差異：

我們使用的趣拍視頻雲服務的直播拉流技術提供了以上三種格式，滿足不同業務場景的需求，如對即時性要求較高或有互動需求的可以採用RTMP或FLV格式進行直播拉流播放；對於有回放或跨平台需求的，推薦使用HLS。當然，三種協議是可以同時使用的，分別用到自己的場景就可以了。

2、解碼和渲染

拉流獲取封裝的視頻數據後，必須通過解碼器解碼、渲染後才能在播放器上播放。它是編碼的逆過程，是指從音視頻的數據中提取原始數據。前面介紹的H.264和H.265編碼格式都是有損壓縮，所以在提取後的原始數據，並非原始採樣數據，存在一定的信息丟失。因此，在視頻體積最小的情況下通過各種編碼參數保留最好的原始畫面，成為了各視頻公司的核心機密。

考慮對高清的支持，解碼肯定還是要選擇硬解碼的。前面介紹過，iOS系統由於硬體比較單一、比較封閉，支持的比較好，Android系統由於平台差異非常大，編解碼要完全兼容各平台還需要很多工作要做。

四、移動直播中的交互系統

移動直播中最常見的交互有聊天室（彈幕）、點贊、打賞和禮物等，交互系統涉及消息的實時性和互動性，在技術實現上大多是使用IM的功能來實現的。對於在線人數比較多的房間，彈幕消息量是非常大，主播與用戶其實都看不過來，為了緩解伺服器壓力，在產品策略需要做一些必要的優化。

1、聊天室

移動直播中的彈幕交互是用戶和主播互動的主要方式，實際上就是IM中的聊天室功能。聊天室和群聊功能類似，但聊天室的消息是不需要分發給不在線的用戶的，歷史消息也不需要查看，用戶只有進入聊天室後才能查看聊天消息和群成員信息。面對複雜多變的網路狀況，還需要根據用戶位置就近選擇近對應運營商的單線機房接入彈幕消息服務，讓彈幕更及時。

2、禮物系統

禮物系統更是絕大多數移動直播平台的標配了，它是這些平台主要的收入來源。送禮物的形式也增強了用戶和主播之間的互動交流，也是主播依賴平台的最主要原因。

禮物的收發在技術實現上也是用聊天室介面做的，通常採用IM中的自定義消息實現，當用戶收到或發送禮物時將自定義消息對應的禮物圖形渲染出來。

以上就是我們在使用了第三方SDK服務後總結出來的直播產品經驗，希望能幫助到創業者和從業者們。

視頻直播，主要涉及到採集、預處理、編碼、傳輸、伺服器轉碼、解碼這樣一個流程。如圖所示

一、採集：主要包含圖像採集和音頻採集；

圖像採集設置前置攝像頭、後置攝像頭，並配置採集的參數、圖像數據的長寬、fps、輸出的方向、橫屏豎屏等，然後從回調中取到數據。

音頻採集和編碼主要面臨的挑戰在於：雜訊消除（Denoise）、回聲消除（AEC）演算法等。

前期不需要音頻數據處理需求的時候，只需配置音頻採集的採樣頻率、採樣精度和聲道。

二、預處理：分為音頻處理和視頻處理兩個方面。

音頻處理是直播難點之一，尤其主播離手機有一段距離，直播環境會有噪音，所以直播的音頻處理是整體降噪的過程。增益降噪等處理可直接從speex項目中抽出來的聲音處理代碼，然後調用、處理。如有類似在直播的時候播放背景音樂的混音需求，就需要使用 Audio Unit 來實現音頻數據的混音，而還需要將混音的背景音樂轉成 PCM 數據，拷貝一份送入混音，原來的數據送入播放器。

濾鏡、美顏功能是直播標配，如果需要美白、水印、裁剪等處理效果，就必須處理拿到的buffer, 這個時候還要考慮到拿到的數據是YUV還是RGB。iOS上是不能對YUV格式直接進行美顏處理，只能是 RGB 格式。可選擇使用 GPUImage 庫，調用 GPUImage 來進行採集和美白、水印、裁剪的處理，然後取出來進行編碼上傳，並顯示在預覽畫面上。

三、編碼：

軟編碼：現在廣泛採用FFmpeg庫結合編碼庫來實現，FFmpeg + x264 來編碼視頻數據YUV/RGB輸出H264數據， FFmpeg+fdk_aac 來編碼音頻數據PCM輸出AAC數據。

硬編碼: iOS 8之後開放了硬解碼和硬編碼AP，所以基本上都是選擇VideoToolBox 和 AudioToolBox 進行圖像和音頻的硬編碼。

四、傳輸：

又拍雲播放器採用 FFMPEG 進行數據的接收，推流端默認使用 FFMPEG 進行數據的封包發送。

相對來說，封包最主要注意的一個點是時間戳。因為用的AVPacket封包，每個包都會有一個DST(Decode Time Stamp)、PST (Presentation Time Stamp)參數，從字面上可以理解，就是解碼時間和顯示時間，在沒有B幀存在的情況下DTS的順序和PTS的順序應該是一樣的。這塊還涉及到重連和丟幀，用戶的網路情況波動斷開了,會進行重連。重連失敗之後才會發送失敗回調。丟幀是一個弱網情況的策略，根據音視頻數據的緩衝區大小來判斷是否丟幀,丟幀會優先丟非關鍵幀,保留關鍵幀，而一旦需要丟關鍵幀的時,關鍵幀後的非關鍵幀也會一起丟掉直到下一個關鍵幀.來保證畫面不會花屏。

五、服務端

現在主流的兩種推送協議是 RTMP 和 HLS，兩者的優缺點我就不在這裡做比較了。又拍雲採用用的是 RTMP 協議。

六、播放器

播放器主要負責拉流、解碼、播放。

1、解析協議

播放器端根據URL解析所用的流媒體協議（RTMP，HLS）。

2、解封裝

解封裝，就是demux的過程，從容器格式（FLV，TS）中，分離出音視頻數據。

3、解碼

解碼，就是把獲取到的數據解壓縮，恢復成原始數據。解碼就是將H264變成YUV，AAC變成PCM。解碼可以使用軟解碼，硬解碼。

4、渲染數據

採用OpenGL渲染YUV數據，呈現視頻畫面。將PCM送入設備的硬體資源播放，產生聲音。

iOS播放流式音頻，使用Audio Queue 的方式，即利用AudioToolbox.Framework 框架。

推薦閱讀：

從Html5直播到互動直播，看直播協議的選擇

WebSocket+MSE——HTML5 直播技術解析

技術乾貨|又拍雲直播轉碼系統架構與實踐

可以找專業團隊來做，99直播系統已經為400多家客戶做過直播系統了，搭建示意圖

金融直播_99金融直播系統（一、前端頁面功能演示）—在線播放—優酷網，視頻高清在線觀看視頻

非常同意上面的說法，付費購買成熟直播平台真的最划算。拿我們自家因酷產品來講，客戶只要花個幾千塊錢，我們這邊當天最遲第二天就把直播系統給到客戶手中了。定製的話周期可能長些，但真的是省很多事，要知道自己開發個直播系統先不說時間問題，開發出來能不能用還待考慮，畢竟對於客戶需求不清楚，無論人力物力財力都不值當。

喬韻直播系統是一款完善且功能齊全的視頻直播平台系統程序，它擁有諸多功能，且有完善的後台運營管理系統。

前台視頻直播系統包括主播系統，禮物系統，遊戲系統，道具系統，代理功能，排行榜，充值系統，個人中心，守護系統等。

後台系統包括基礎設置，用戶管理，財務結算，界面樣式，資料庫管理，活動管理等。

專業的團隊，應對專業的問題

使用我們的支撐服務，我們提供全方位的業務保障

我們擁有實力強勁的研發團隊，實力非凡的架構團隊，專業的運維團隊

其實付費購買成熟直播平台是比較划算的，你把精力可以放到內容上。軟體外包的有美麗播、紅鳥什麼的，特點是你擁有源碼，但是價格非常高（10w+），需要後期維護。直播雲SaaS的貌似有噴泉雲（應該是這個名字，建議百度下），特點是沒有源碼，不過價格便宜，無需維護。類似阿里雲一樣，全套自有的平台，只不過是在雲端。