聯(lián)誠發(fā)

音視頻技術(shù)介紹

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

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

音視頻的主要處理過程：

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

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

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

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

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

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

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

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

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

視頻參數(shù)：

1. 分辨率：視頻面積大小（像素px）；

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

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

音頻參數(shù)：

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

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

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

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

視頻：YUV、RGB；

音頻：PCM

編碼格式：

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

音頻：AAC、Opus

封裝格式：

視頻：MP4、FLV、TS；

音頻：不封裝

視頻幀與音頻幀

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

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

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

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

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

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

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

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

在直播中，基本上不會出現(xiàn)B幀，因為B幀是需要解析了前后兩個幀之后做對比產(chǎn)生的，在直播這種最求速度和畫質(zhì)的場景中，如果使用B幀，會因為大量解析的時間增加不少延遲，但是也不能全是I幀，I幀的數(shù)據(jù)量太大，全是I幀的話，效率也會很差，所以直播一般是用的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，大廠面試題 等）

視頻清晰度

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

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

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

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

一般來說：30fps左右可以感覺動作已經(jīng)是連貫的了；60fps體驗已經(jīng)可以達到逼真感；超過75fps，一般就沒法察覺流暢度的提升了。

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

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

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

再來說說GOP對畫質(zhì)的影響，前面有說過，GOP就是一個I幀與下一個I幀之間的幀組合，比如IBBPBBP...之類的，在一組GOP中，因為B和P幀只記錄了差值，所以需要的數(shù)據(jù)量比I幀少很多。

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

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

音畫同步

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

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

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

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

音畫同步算法

流媒體協(xié)議

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

JitterBuffer帶來的好處就是：

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

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

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

總結(jié)

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