隨著網(wǎng)絡(luò)基礎(chǔ)建設(shè)的發(fā)展和資費的下降，在這個內(nèi)容消費升級的時代，文字、圖片無法滿足人們對視覺的需求，因此視頻直播應(yīng)運而生。承載了實時性Real-Time和交互性的直播云服務(wù)是直播覆蓋各行各業(yè)的新動力。網(wǎng)易云信推出一系列文章，對視頻直播技術(shù)進行深入講解，本篇文章將向大家介紹iOS端的推流技術(shù)。

?

相關(guān)閱讀推薦

《視頻直播：Windows中各類畫面源的截取和合成方法總結(jié)》

《視頻直播關(guān)鍵技術(shù)：流暢、擁塞和延時追趕》

《短視頻技術(shù)詳解：Android端的短視頻開發(fā)技術(shù)》

?

直播架構(gòu)

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

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

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

直播技術(shù)點

音視頻采集

采集是所有環(huán)節(jié)中的第一環(huán)，我們使用的系統(tǒng)原生框架AVFoundation采集數(shù)據(jù)。通過iPhone攝像頭(AVCaptureSession)采集視頻數(shù)據(jù)，通過麥克風(AudioUnit)采集音頻數(shù)據(jù)。目前視頻的采集源主要來自攝像頭采集、屏幕錄制（ReplayKit）、從視頻文件讀取推流。

音視頻都支持參數(shù)配置。音頻可以設(shè)置采樣率、聲道數(shù)、幀大小、音頻碼率、是否使用外部采集、是否使用外部音頻前處理；視頻可以設(shè)置幀率、碼率、分辨率、前后攝像頭、攝像頭采集方向、視頻端顯示比例、是否開啟攝像頭閃光燈、是否打開攝像頭響應(yīng)變焦、是否鏡像前置攝像頭預(yù)覽、是否鏡像前置攝像頭編碼、是否打開濾鏡功能、濾鏡類型、是否打開水印支持、是否打開QoS功能、是否輸出RGB數(shù)據(jù)、是否使用外部視頻采集。

音視頻處理

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

音視頻編碼

編碼最主要的兩個難點是:

處理硬件兼容性問題

在高FPS、低bitrate和音質(zhì)畫質(zhì)之間找個一個平衡點

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

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

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

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

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

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

?

音視頻發(fā)送

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

?

模塊設(shè)計&線程模型

模塊設(shè)計

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

線程模型

推流SDK總共含有10個線程。視頻包含AVCaptureSession的原始采集線程、前處理線程、硬件編碼線程、數(shù)據(jù)流向定義的采集線程、編碼線程、發(fā)送線程。音頻包含AudioUnit包含的原始采集線程、數(shù)據(jù)流向定義的采集線程、編碼線程、發(fā)送線程。在數(shù)據(jù)流向定義的采集線程、編碼線程、發(fā)送線程之間會創(chuàng)建2個bufferQueue，用于緩存音視頻數(shù)據(jù)。采集編碼隊列可以有效的控制編碼碼率，編碼發(fā)送隊列可以有效自適應(yīng)網(wǎng)絡(luò)推流。

QoS&跳幀

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

以上就是iOS端推流技術(shù)的詳細講解。

另外，想要關(guān)于視頻直播技術(shù)的文章，可以移步網(wǎng)易云信博客。

?

總結(jié)

以上是生活随笔為你收集整理的视频直播技术之iOS端推流的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。