聯(lián)誠(chéng)發(fā)

音視頻技術(shù)介紹

什么是音視頻技術(shù)？音視頻技術(shù)其實(shí)就是音頻技術(shù)和視頻技術(shù)的一個(gè)統(tǒng)稱，在技術(shù)處理上，其實(shí)音頻和視頻是要分開(kāi)處理的。

而且要注意一點(diǎn)，音視頻從開(kāi)始收集數(shù)據(jù)到最后展示都是離不開(kāi)硬件設(shè)備的，所以在以后的開(kāi)發(fā)過(guò)程中，要做好與硬件打交道的心理準(zhǔn)備了。

音視頻的主要處理過(guò)程：

1. 采集。比如從客戶端的攝像頭、麥克風(fēng)和本地原始文件等，獲得基礎(chǔ)的音視頻數(shù)據(jù)；

2. 預(yù)處理。在這個(gè)階段其實(shí)就是對(duì)音視頻進(jìn)行修剪操作，畢竟收集到的原始數(shù)據(jù)，不一定是想要在最后呈現(xiàn)的效果，因此在這里可能會(huì)進(jìn)行美顏、裁剪、AI識(shí)別處理、聲音A3處理等；

3. 編碼。在經(jīng)過(guò)預(yù)處理或者沒(méi)處理過(guò)的原始文件，一般都會(huì)比較大，不適合進(jìn)行傳輸，這個(gè)時(shí)候就需要進(jìn)行壓縮、轉(zhuǎn)碼之類的操作，減少文件提交，然后再進(jìn)行傳輸，執(zhí)行編碼的工具叫編碼器，壓縮數(shù)據(jù)的算法叫做編碼格式；

4. 解碼。壓縮數(shù)據(jù)傳輸完之后，就需要解碼成原始文件一樣的數(shù)據(jù)才能使用，用來(lái)解碼的工具就是解碼器了，不過(guò)通常編碼器和解碼器是一塊的，統(tǒng)稱為編解碼器codec；

5. 渲染與展示。接收到原始數(shù)據(jù)文件之后，就可以通過(guò)硬件或者軟件進(jìn)行渲染與展示了，硬件例如顯示器、音響等，軟件有SurfaceView；

6. 文件封裝/解封裝。其實(shí)從采集，音頻和視頻都是分開(kāi)進(jìn)行處理的，但是在進(jìn)行傳輸?shù)臅r(shí)候，我們需要同一套音頻文件是在一塊的，所以需要進(jìn)行一次文件封裝。存放音視頻的容器叫封裝容器，文件類型叫封裝格式；

7. 網(wǎng)絡(luò)協(xié)議打包。音視頻文件在網(wǎng)絡(luò)中傳輸?shù)臅r(shí)候，一般都會(huì)有一個(gè)特定的協(xié)議，也就是流媒體協(xié)議。

網(wǎng)絡(luò)協(xié)議會(huì)將音視頻數(shù)據(jù)文件打包成協(xié)議包，通過(guò)網(wǎng)絡(luò)協(xié)議端口發(fā)送出去，接收方接收到網(wǎng)絡(luò)包之后，要通過(guò)網(wǎng)絡(luò)協(xié)議解開(kāi)協(xié)議包，才能獲得音視頻數(shù)據(jù)文件。

音視頻主要參數(shù)即格式

視頻參數(shù)：

1. 分辨率：視頻面積大?。ㄏ袼豴x）；

2. 幀率：每秒的幀數(shù)量fps；

3. 碼率：每秒的數(shù)據(jù)量bps（b = bit）。

音頻參數(shù)：

1. 采樣率：每秒采集的音頻點(diǎn)數(shù)量Hz；

2. 聲道數(shù)：同時(shí)采集聲音的通道數(shù)量，常見(jiàn)有單聲道和立體聲道；

3. 位寬：也叫采樣位寬，指保存單個(gè)聲音樣本點(diǎn)的比特位數(shù)，通常是16bit。

原始數(shù)據(jù)格式：

視頻：YUV、RGB；

音頻：PCM

編碼格式：

視頻：H.264（也叫AVG）;

音頻：AAC、Opus

封裝格式：

視頻：MP4、FLV、TS；

音頻：不封裝

視頻幀與音頻幀

視頻幀就相當(dāng)于一張圖片，多個(gè)圖片組合以極快的速度切換，就可以形成一段視頻。雖說(shuō)只是圖片，但是視頻幀有很多種類之分，后面我會(huì)進(jìn)行介紹。

目前視頻幀主要分為一下幾種：

1. I幀即關(guān)鍵幀，記錄了一個(gè)完整的圖像，可以被直接解碼顯示，兩個(gè)I幀中間的一組幀稱之為一個(gè)GOP（group of picture）；

2. P幀，不記錄畫(huà)面，記錄的是本幀與前一幀的差異，P幀不能直接解碼，需要先解碼前序的參考幀；

3. B幀是記錄了本幀與前一個(gè)I/P幀和后一個(gè)I/P幀的差異；

4. 剩下的還有SI和SP幀，這倆是用于切換碼流使用，一般不常見(jiàn)。

P幀和B幀主要是用來(lái)壓縮視頻用的，大概原理可以理解，I幀存儲(chǔ)的是原圖像，那么存儲(chǔ)的數(shù)據(jù)量也會(huì)比較大，如果I幀出現(xiàn)的占比越多，那么整個(gè)視頻的數(shù)據(jù)量也就越多。

這個(gè)時(shí)候P幀和B幀的出現(xiàn)，可以明顯的減少數(shù)據(jù)量，P幀只會(huì)對(duì)比前一個(gè)P幀或者I幀的差異，并存儲(chǔ)下來(lái)，數(shù)據(jù)量比I幀小了很多，大概壓縮比有20左右，另外B幀會(huì)對(duì)比前一個(gè)I/P幀、后一個(gè)I/P幀與本幀的差異，并進(jìn)行存儲(chǔ)，因?yàn)閷?duì)比了兩個(gè)幀，所以B幀存儲(chǔ)的數(shù)據(jù)量就會(huì)更小，壓縮比能達(dá)到50。

在直播中，基本上不會(huì)出現(xiàn)B幀，因?yàn)锽幀是需要解析了前后兩個(gè)幀之后做對(duì)比產(chǎn)生的，在直播這種最求速度和畫(huà)質(zhì)的場(chǎng)景中，如果使用B幀，會(huì)因?yàn)榇罅拷馕龅臅r(shí)間增加不少延遲，但是也不能全是I幀，I幀的數(shù)據(jù)量太大，全是I幀的話，效率也會(huì)很差，所以直播一般是用的I幀和P幀組合。

【文章福利】需要C/C++ Linux服務(wù)器架構(gòu)師及音視頻學(xué)習(xí)資料加群812855908（資料包括C/C++，Linux，golang技術(shù)，內(nèi)核，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，音視頻，CDN，P2P，K8S，Docker，TCP/IP，協(xié)程，DPDK，ffmpeg，大廠面試題 等）

視頻清晰度

一個(gè)視頻的畫(huà)質(zhì)與視頻的碼率、分辨率、壓縮比、幀率、GOP長(zhǎng)度有關(guān)。只有他們達(dá)到了最佳平衡，才能呈現(xiàn)最佳的畫(huà)質(zhì)。

比如說(shuō)，分辨率，一般在我們的印象中，就是越高，畫(huà)質(zhì)就越清晰，這也是沒(méi)毛病的，畢竟分辨率越高，畫(huà)面分配到的像素點(diǎn)越多，細(xì)節(jié)描繪就越好，但是要注意，分辨率越高，帶來(lái)的問(wèn)題就是數(shù)據(jù)量越大，數(shù)據(jù)量越大，那就代表著需要的碼率也就越高，只有碼率高了才能保證我們視頻數(shù)據(jù)的正常輸出，如果碼率低了，就是造成視頻的卡頓，也就是我們?？匆?jiàn)的“視頻緩存中”。

不過(guò)現(xiàn)在很多視頻軟件也會(huì)做一些操作來(lái)降低碼率帶來(lái)的卡頓效果，比如調(diào)節(jié)壓縮比，壓縮比高了，數(shù)據(jù)量就小了，需要的碼率也就降低了，當(dāng)然犧牲的就是原視頻的分辨率了。目前很多軟件會(huì)自動(dòng)幫你調(diào)節(jié)壓縮比。

那么幀率又在其中起到了什么作用呢？玩游戲的都知道，幀率越高，游戲的流暢度就越高，幀率就是視頻的刷新率，也就是一秒鐘刷新的幀數(shù)，比如說(shuō)幀率30fps，你就可以理解成，30幅連續(xù)動(dòng)作的畫(huà)一秒鐘從你眼前閱過(guò)。

一般來(lái)說(shuō)：30fps左右可以感覺(jué)動(dòng)作已經(jīng)是連貫的了；60fps體驗(yàn)已經(jīng)可以達(dá)到逼真感；超過(guò)75fps，一般就沒(méi)法察覺(jué)流暢度的提升了。

幀率有顯示器幀率和視頻幀率之分，這一點(diǎn)是要注意不要混淆了。那我們這里可以探討一下如果視頻幀率與顯示器幀率不同的情況下會(huì)出現(xiàn)什么情況。

其實(shí)視頻幀率就是顯卡繪制圖形速度控制的，假如說(shuō)你的顯卡繪制速度是30fps，而顯示器的幀率是60fps，顯示器刷新的速度比顯卡繪制速度快，這個(gè)時(shí)候顯示器就只是刷新最新的那些幀，在觀看體驗(yàn)上并不會(huì)有什么差異。

但是如果顯示器的幀率是30fps，而顯卡是60fps，那就問(wèn)題來(lái)了，因?yàn)轱@卡繪制圖形速度過(guò)快，而顯示器刷新速度太慢，就會(huì)導(dǎo)致有的幀被緩存下來(lái)，當(dāng)緩存區(qū)別放慢了之后，后面繼續(xù)進(jìn)來(lái)的數(shù)據(jù)就會(huì)把之前的數(shù)據(jù)擠走，這就導(dǎo)致了顯示器當(dāng)前幀與緩存區(qū)下一幀不是連貫的，也就會(huì)出現(xiàn)了“畫(huà)面撕裂”。

再來(lái)說(shuō)說(shuō)GOP對(duì)畫(huà)質(zhì)的影響，前面有說(shuō)過(guò)，GOP就是一個(gè)I幀與下一個(gè)I幀之間的幀組合，比如IBBPBBP...之類的，在一組GOP中，因?yàn)锽和P幀只記錄了差值，所以需要的數(shù)據(jù)量比I幀少很多。

所以我們可以想象，在有限的數(shù)據(jù)量里邊，如果GOP長(zhǎng)度越長(zhǎng)，I幀所分到的數(shù)據(jù)量就能越多，I幀的質(zhì)量就可以更高，I幀又是GOP的基準(zhǔn)幀，那么整體的畫(huà)質(zhì)也就提升了。

但是不是GOP越長(zhǎng)，就越好呢？回答當(dāng)然是no，根據(jù)之前說(shuō)的，P和B幀都是參考I幀生成的，有依賴關(guān)系，解析時(shí)間比I幀長(zhǎng)很多，設(shè)置過(guò)多的B、P幀那就代表著在解析上面就要花費(fèi)更多的時(shí)間，另外如果他們參照的I幀出現(xiàn)了數(shù)據(jù)問(wèn)題，那么這一組GOP的數(shù)據(jù)就全部出錯(cuò)。由此看見(jiàn)，GOP也并不是越長(zhǎng)越好。

音畫(huà)同步

我們都知道，播放器在處理音視頻的時(shí)候是分開(kāi)進(jìn)行解碼渲染的，那么又如何才能達(dá)到音畫(huà)同步呢？我們可以聯(lián)想到我們的現(xiàn)實(shí)世界，我們是如何理解同步這個(gè)概念，其實(shí)同步就是指的同時(shí)發(fā)生。

那么要做到音畫(huà)同步也就是說(shuō)我們要給音畫(huà)添加上時(shí)間戳(PTS)的概念，時(shí)間相近的音頻幀和視頻幀，我們就認(rèn)定為是同步的兩個(gè)幀，這個(gè)相近值我們可以叫他閾值，這個(gè)閾值并不是隨意定義的，他有一個(gè)國(guó)際標(biāo)準(zhǔn)叫RFC-1359.

一般音視頻同步的做法有三種：視頻同步到音頻、音頻同步到視頻、音視頻同步的外部時(shí)鐘。

通常采用視頻同步到音頻的方法。這是因?yàn)橐曨l是一幀一幀播放的，而音頻則是一個(gè)流式的播放形式，也就是連續(xù)不間斷的形式，在處理邏輯上，處理一幀幀播放的視頻會(huì)來(lái)的更加方便。音視頻同步的算法如下圖所示：

音畫(huà)同步算法

流媒體協(xié)議

通常音視頻數(shù)據(jù)體積比較大，所以在網(wǎng)絡(luò)傳輸過(guò)程中都是連續(xù)不斷的多媒體流量，在網(wǎng)絡(luò)中傳輸音視頻數(shù)據(jù)的技術(shù)叫流媒體技術(shù)，傳輸使用的協(xié)議就是流媒體協(xié)議。

通常使用的流媒體協(xié)議有一下幾種：

1. RTMP：基于TCP七層協(xié)議，性價(jià)比高，是目前直播推流的標(biāo)準(zhǔn)使用協(xié)議；

2. HTTP-FLV：基于TCP，使用HTTP傳輸FLV流，分發(fā)性能強(qiáng)，適用于CDN分發(fā)；

3. HLS：基于TCP，被HTML5寫(xiě)入標(biāo)準(zhǔn)支持，延時(shí)大，但是兼容H5；

4. RTP：基于UDP四層協(xié)議，定義簡(jiǎn)單且性能好，但是需要額外的信令協(xié)議。

除了以上四種之外，有些廠商還會(huì)有自己的協(xié)議已達(dá)到特定的傳輸目的。

網(wǎng)絡(luò)抖動(dòng)

首先要先來(lái)熟悉一下幾個(gè)衡量網(wǎng)絡(luò)好壞的指標(biāo)：

1. 丟包率：(本端接收到的數(shù)據(jù)包/對(duì)端發(fā)送的數(shù)據(jù)包) * 100%；

2. 延時(shí)：對(duì)端接收時(shí)間T1-本端發(fā)送數(shù)據(jù)時(shí)間T0，一般用RTT來(lái)評(píng)估延時(shí)，即往返延時(shí)，本端發(fā)送數(shù)據(jù)，到對(duì)端接收數(shù)據(jù)并確認(rèn)接收的耗時(shí)；

3. 帶寬：網(wǎng)口允許收發(fā)數(shù)據(jù)量的大小，單位bps，發(fā)送速率：實(shí)際收發(fā)的數(shù)據(jù)量的大小，單位bps。帶寬可以理解成最大發(fā)送速率；

網(wǎng)絡(luò)抖動(dòng)就是實(shí)際發(fā)（收）的數(shù)據(jù)沒(méi)有發(fā)（收），判斷是否抖動(dòng)就是看丟包率是否增加、 RTT是否增加、發(fā)送速率是否降低。

JitterBuffer就是為了減少網(wǎng)絡(luò)抖動(dòng)給音視頻傳輸帶來(lái)的影響而產(chǎn)生的，jitterBuffer是傳輸過(guò)程中的一個(gè)緩沖區(qū)，連接著解碼器和網(wǎng)絡(luò)協(xié)議棧。

JitterBuffer會(huì)有一的延遲音視頻傳輸時(shí)間，將數(shù)據(jù)先緩存在緩沖區(qū)中，并且也會(huì)將之前緩存的數(shù)據(jù)發(fā)送到接收端，我就把他理解成我們?cè)诰W(wǎng)上看電視的時(shí)候的視頻緩存，這樣的話，即使出現(xiàn)了偶爾的網(wǎng)絡(luò)抖動(dòng)，也不會(huì)影響到用戶的體驗(yàn)。

JitterBuffer帶來(lái)的好處就是：

1. 降低了網(wǎng)絡(luò)輕微抖動(dòng)打來(lái)的卡頓；

2. 平衡編解碼器和網(wǎng)絡(luò)協(xié)議棧的數(shù)據(jù)供求量；

3. 動(dòng)態(tài)調(diào)整數(shù)據(jù)的收發(fā)量，在一定范圍內(nèi)控制數(shù)據(jù)收發(fā)平衡性。

總結(jié)

以上是聯(lián)誠(chéng)發(fā)小編整合了一些其他大佬的資料和一些自己的理解寫(xiě)出的知識(shí)點(diǎn)，音視頻技術(shù)涵蓋的內(nèi)容其實(shí)比較廣泛的，我這里也僅僅是列出了一些基礎(chǔ)的概念，后續(xù)的TRTC學(xué)習(xí)之旅，有機(jī)會(huì)的話，聯(lián)誠(chéng)發(fā)LED顯示屏小編繼續(xù)與大家探討一些其他的知識(shí)。