在開發(fā)直播系統(tǒng)時，需要用到的技術(shù)非常多，例如：音視頻采集與處理、音視頻壓縮、CDN分發(fā)等，每一個技術(shù)都夠?qū)W好久了，下面就給大家介紹下一些常見的直播系統(tǒng)開發(fā)技術(shù)。

一、采集:包括圖像采集和音頻采集。

圖像采集設置前置攝像頭和后置攝像頭，并配置采集參數(shù)、圖像數(shù)據(jù)的長度和寬度、fps、輸出方向、水平屏幕和垂直屏幕等。，然后從回調(diào)中獲取數(shù)據(jù)。音頻采集和編碼面臨的主要挑戰(zhàn)是:噪聲消除、回聲消除算法等。當前期不需要音頻數(shù)據(jù)處理時，只需要配置音頻采集的采樣頻率、采樣精度和頻道。

二、預處理。

現(xiàn)在美顏已是標配，80%的主播沒有美顏根本不能看。

美容算法需要GPU編程，需要懂圖像處理算法的人，沒有好的開源實現(xiàn)，需要參考論文進行研究。難點不在于美容效果，而在于GPU占用和美容效果之間的平衡。GPU雖然性能好，但也有功耗。GPU占用過高會導致手機燙傷，手機燙傷會導致攝像機采集掉幀，可能是因為過熱會導致CPU降低主頻。

三、代碼。

一定要使用硬碼，軟碼720p完全沒有希望，勉強能夠編碼也會導致CPU過熱燙到攝像機。

硬碼兼容又是一個大坑，android上要有人填寫。在分辨率、幀速率、碼速率、GOP等參數(shù)設計中，編碼應找到最佳平衡。

四、傳輸。

封包最重要的一點是時間戳。

由于使用的AVPacket封包，每一個封包都會有一個DST(DecodeTimeStamp),PST(PresentationTimeStamp)參數(shù)，從字面上可以理解，即解碼時間和顯示時間，在沒有B幀的情況下，DTS的順序和PTS的順序應該是相同的。此塊還涉及到重連和丟幀，當用戶的網(wǎng)絡波動斷開時，將進行重連。如果不想卡頓，必須增加緩沖，會導致高延遲，高延遲會影響交互性，權(quán)衡。

五、解碼和渲染。

獲得封裝視頻數(shù)據(jù)后，必須通過解碼器解碼、渲染后才能在播放器上播放。

這是編碼的逆過程，是指從音視頻數(shù)據(jù)中提取原始數(shù)據(jù)。上述H.264和H.265編碼格式都是有損壓縮的，因此提取的原始數(shù)據(jù)，并非原始采樣數(shù)據(jù)，而是存在一定的信息丟失。

六、推流。

為了推流，還必須使用傳輸協(xié)議將音視頻數(shù)據(jù)封裝成流數(shù)據(jù)。

常用的傳輸協(xié)議包括RTSP、RTMP、HLS等。用RTMP傳輸?shù)难舆t通常為1~3秒，在手機轉(zhuǎn)播這一實時性非常高的情況下，RTMP也成為手機轉(zhuǎn)播中最常用的傳輸協(xié)議。

七、拉流。

拉流其實是推流的逆過程。

先從播放端獲取碼流，標準的拉流格式有RTMP,HLS,FLV等。RTMP是Adobe的專利協(xié)議，開放源碼軟件和開放源碼庫都支持得比較好，比如開放源碼的librtmp庫，播放端只要支持flashPlayer，就可以非常簡單地播放RTMP直播，直播延遲一般為1-3秒。Apple提出了基于HTTP的流媒體傳輸協(xié)議，HTML5可以直接打開播放，通過微信、QQ等軟件共享，用戶也可以直接觀看直播，可以說手機直播app，HLS拉流協(xié)議是必須支持的。

八、錄像直播連麥。

直播期間，直播者通過麥克風、攝像頭等工具與觀眾交流。

協(xié)助雙方進行更有效的溝通，也能給更多的行業(yè)場景帶來極大的體驗提升。而且連麥技術(shù)的創(chuàng)新更是的多人連麥互動成為可能。

上述就是媒體模塊，其他的直播系統(tǒng)開發(fā)技術(shù)還有信令控制，登錄，鑒權(quán)，權(quán)限管理，狀態(tài)管理等，各種應用服務，信息推送，聊天，禮品系統(tǒng)，支付系統(tǒng)，操作支持系統(tǒng)。還有數(shù)據(jù)庫，緩存，分布式文件存儲，信息隊列，運行系統(tǒng)等。

每一個技術(shù)都不是一兩天能掌握的，所以想擁有自己的直播系統(tǒng)除了找有經(jīng)驗的人來幫忙，最好的辦法還是找第三方來開發(fā)，因為不管是在技術(shù)、CDN、帶寬上都是有很高門檻的。直播系統(tǒng)開發(fā)技術(shù)不過關(guān)，后期一旦出現(xiàn)問題，將會導致所有努力付之東流。