摘要：目前視頻的采集源主要來(lái)自攝像頭采集屏幕錄制從視頻文件讀取推流。音視頻處理前處理模塊也是主觀影響主播觀看效果最主要的環(huán)節(jié)。用戶停止直播，反初始化，銷(xiāo)毀線程。跳幀可以有效的解決用戶在網(wǎng)絡(luò)不好的情況下，直播卡頓的問(wèn)題。

隨著網(wǎng)絡(luò)基礎(chǔ)建設(shè)的發(fā)展和資費(fèi)的下降，在這個(gè)內(nèi)容消費(fèi)升級(jí)的時(shí)代，文字、圖片無(wú)法滿足人們對(duì)視覺(jué)的需求，因此視頻直播應(yīng)運(yùn)而生。承載了實(shí)時(shí)性Real-Time和交互性的直播云服務(wù)是直播覆蓋各行各業(yè)的新動(dòng)力。

想必了解過(guò)直播的人都清楚直播主要分為3部分：推流->流媒體服務(wù)器->拉流。

而我們今天需要講的就是推流這部分，它主要包括音視頻采集，音視頻前處理，音視頻編碼，推流和傳輸4個(gè)方面。但是由于網(wǎng)絡(luò)的復(fù)雜性和大數(shù)據(jù)的統(tǒng)計(jì)，推流還需要有全局負(fù)載均衡調(diào)度 GSLB（Global Server Load Balance）,以及實(shí)時(shí)的統(tǒng)計(jì)數(shù)據(jù)上報(bào)服務(wù)器，包括提供頻道管理給用戶運(yùn)營(yíng)，因此推流 SDK 需要接入 GSLB 中心調(diào)度，統(tǒng)計(jì)服務(wù)器，心跳服務(wù)器，用于推流分配到網(wǎng)絡(luò)最好的節(jié)點(diǎn)，有大數(shù)據(jù)的統(tǒng)計(jì)和分析。

下圖涵蓋了直播相關(guān)的所有服務(wù)，紅色小標(biāo)的線條代表指令流向，綠色小標(biāo)的線條代表數(shù)據(jù)流向。

音視頻采集

采集是所有環(huán)節(jié)中的第一環(huán)，我們使用的系統(tǒng)原生框架 AVFoundation 采集數(shù)據(jù)。通過(guò) iPhone 攝像頭(AVCaptureSession)采集視頻數(shù)據(jù)，通過(guò)麥克風(fēng)(AudioUnit)采集音頻數(shù)據(jù)。目前視頻的采集源主要來(lái)自攝像頭采集、屏幕錄制（ReplayKit）、從視頻文件讀取推流。
音視頻都支持參數(shù)配置。音頻可以設(shè)置采樣率、聲道數(shù)、幀大小、音頻碼率、是否使用外部采集、是否使用外部音頻前處理；視頻可以設(shè)置幀率、碼率、分辨率、前后攝像頭、攝像頭采集方向、視頻端顯示比例、是否開(kāi)啟攝像頭閃光燈、是否打開(kāi)攝像頭響應(yīng)變焦、是否鏡像前置攝像頭預(yù)覽、是否鏡像前置攝像頭編碼、是否打開(kāi)濾鏡功能、濾鏡類(lèi)型、是否打開(kāi)水印支持、是否打開(kāi) QoS 功能、是否輸出 RGB 數(shù)據(jù)、是否使用外部視頻采集。

音視頻處理

前處理模塊也是主觀影響主播觀看效果最主要的環(huán)節(jié)。目前 iOS 端比較知名的是 GPUImage，提供了豐富的預(yù)處理效果，我們也在此基礎(chǔ)上進(jìn)行了封裝開(kāi)發(fā)。視頻前處理包含濾鏡、美顏、水印、涂鴉等功能，同時(shí)在人臉識(shí)別和特效方面接入了第三方廠商 FaceU。SDK 內(nèi)置 4 款濾鏡黑白、自然、粉嫩、懷舊；支持 16:9 裁剪；支持磨皮和美白（高斯模糊加邊緣檢測(cè)）；支持靜態(tài)水印，動(dòng)態(tài)水印，涂鴉等功能。音頻前處理則包括回聲抑制、嘯叫、增益控制等。音視頻都支持外部前處理。

音視頻編碼

編碼最主要的兩個(gè)難點(diǎn)是:

處理硬件兼容性問(wèn)題

在高FPS、低bitrate和音質(zhì)畫(huà)質(zhì)之間找個(gè)一個(gè)平衡點(diǎn)

由于iOS端硬件兼容性比較好，因此可以采用硬編。SDK 目前支持軟件編碼 openH264，硬件編碼 VideoToolbox。而音頻支持軟件編碼 FDK-AAC 和硬件編碼 AudioToolbox。

視頻編碼的核心思想就是去除冗余信息：

空間冗余:圖像相鄰像素之間有較強(qiáng)的相關(guān)性。

時(shí)間冗余:視頻序列的相鄰圖像之間內(nèi)容相似。

編碼冗余:不同像素值出現(xiàn)的概率不同。

視覺(jué)冗余:人的視覺(jué)系統(tǒng)對(duì)某些細(xì)節(jié)不敏感。

音視頻發(fā)送

推流 SDK 使用的流媒體協(xié)議是 RTMP（RealTime Messaging Protocol）。而音視頻發(fā)送最困難的就是針對(duì)網(wǎng)絡(luò)的帶寬評(píng)估。由于從直播端到 RTMP 服務(wù)器的網(wǎng)絡(luò)情況復(fù)雜，尤其是在 3G 和帶寬較差的 Wifi 環(huán)境下，網(wǎng)絡(luò)丟包、抖動(dòng)和延遲經(jīng)常發(fā)生，導(dǎo)致直播推流不暢。RTMP 基于 TCP 進(jìn)行傳輸，TCP 自身實(shí)現(xiàn)了網(wǎng)絡(luò)擁塞下的處理，內(nèi)部的機(jī)制較為復(fù)雜，而且對(duì)開(kāi)發(fā)者不可見(jiàn)，開(kāi)發(fā)者無(wú)法根據(jù) TCP 協(xié)議的信息判斷當(dāng)時(shí)的網(wǎng)絡(luò)情況，導(dǎo)致發(fā)送碼率大于實(shí)際網(wǎng)絡(luò)帶寬，造成比較嚴(yán)重的網(wǎng)絡(luò)擁塞。因此我們自研開(kāi)發(fā)了一款實(shí)時(shí)根據(jù)網(wǎng)絡(luò)變化的 QoS 算法，用于實(shí)時(shí)調(diào)節(jié)碼率、幀率、分辨率，同時(shí)將數(shù)據(jù)實(shí)時(shí)上報(bào)統(tǒng)計(jì)平臺(tái)。

模塊設(shè)計(jì)

鑒于推流的主流程分為上述描述的 4 個(gè)部分：音視頻采集、音視頻前處理、音視頻編碼、音視頻發(fā)送。因此將推流 SDK 進(jìn)行模塊劃分為 LSMediacapture 層（對(duì)外 API+ 服務(wù)器交互）、視頻融合模塊（視頻采集+視頻前處理）、音頻融合模塊（音頻采集+音頻前處理）、基礎(chǔ)服務(wù)模塊、音視頻編碼模塊、網(wǎng)絡(luò)發(fā)送模塊。

QoS&跳幀

下圖是直播的主要流程，用戶初始化 SDK，創(chuàng)建線程，開(kāi)始直播，音視頻數(shù)據(jù)采集，編碼，發(fā)送。在發(fā)送線程下，音視頻數(shù)據(jù)發(fā)送，QoS 開(kāi)啟，根據(jù)網(wǎng)絡(luò)實(shí)時(shí)評(píng)估帶寬，調(diào)整幀率，碼率控制編碼器參數(shù)，同時(shí)觸發(fā)跳幀，調(diào)整分辨率控制采集分辨率參數(shù)。用戶停止直播，反初始化 SDK，銷(xiāo)毀線程。QoS &跳幀可以有效的解決用戶在網(wǎng)絡(luò)不好的情況下，直播卡頓的問(wèn)題。在不同的碼率和分辨率情況下，都能夠做到讓用戶流暢地觀看視頻直播。

隨著音頻處理和壓縮技術(shù)的不斷發(fā)展，效果更好、適用范圍更廣、性能更高的算法和新的技術(shù)必將不斷涌現(xiàn)，如果你有好的技術(shù)或者分享，歡迎關(guān)注網(wǎng)易 MC 官方博客以及微信公眾號(hào)：**

關(guān)注更多技術(shù)干貨內(nèi)容：網(wǎng)易云信博客
歡迎關(guān)注網(wǎng)易云信 GitHub
歡迎關(guān)注網(wǎng)易云信官網(wǎng)
官網(wǎng)微信公眾號(hào)：