1. 音視頻基礎(chǔ)

本文將給大家進(jìn)行音視頻基礎(chǔ)的常規(guī)知識(shí)點(diǎn)的梳理。當(dāng)然，短短的一篇文章并不能讓大家立即變成音視頻領(lǐng)域的專家，但這些知識(shí)點(diǎn)已經(jīng)基本涵蓋了音視頻的入門知識(shí)。我們將按照下面的內(nèi)容給大家

• 音視頻的基本概念

• 音視頻播放的流程

• 音視頻編解碼

• 音視頻封裝格式

• 音視頻常見的傳輸協(xié)議

1.1 音視頻基本概念

首先，我們需要先主了解下一些音視頻常見的技術(shù)概念以及簡單的原理。

1.1.1 采樣率

采樣，是指把物理信號(hào)轉(zhuǎn)化為數(shù)字信號(hào)的過程。采樣頻率，定義了每秒從連續(xù)信號(hào)中提取并組成離散信號(hào)的采樣個(gè)數(shù)，單位為赫茲(Hz)。形象來說，采樣頻率是指將模擬信號(hào)轉(zhuǎn)換成數(shù)字信號(hào)時(shí)的采樣頻率，也就是單位時(shí)間內(nèi)采樣多少點(diǎn)。 拿聲音來說，采樣頻率可以是描述聲音文件的音質(zhì)、音調(diào)，衡量聲卡、聲音文件的質(zhì)量標(biāo)準(zhǔn)。采樣頻率越高，即采樣的間隔時(shí)間越短，則在單位時(shí)間內(nèi)計(jì)算機(jī)得到的樣本數(shù)據(jù)就越多，對(duì)信號(hào)波形的表示也越精確。

1.1.2 比特率

比特率是指將模擬信號(hào)轉(zhuǎn)化為數(shù)字信號(hào)后，單位時(shí)間內(nèi)的二進(jìn)制數(shù)據(jù)量，是衡量音視頻質(zhì)量的指標(biāo)之一。單位為比特每秒(bps或者bit/s)。單位時(shí)間內(nèi)比特率越大，精度就越高，處理出來的文件就越接近原始文件，音視頻文件的質(zhì)量也越高。 1000 bit/s = 1 kbit/s （一千位每秒）
1000 kbit/s = 1 Mbit/s （一兆或一百萬位每秒）
1000 Mbit/s = 1 Gbit/s (一吉比特或十億位每秒）
拿聲音來說，能夠分辨語音的最低碼率為800bps，通話質(zhì)量一般來說是8kbps, FM廣播一般是96kbps, MP3文件范圍在8-320kbps之間(一般為128kpbs)， 16位CD一般為 1411kbps。
音頻比特率計(jì)算公式：【比特率】（kbps)=【量化采樣點(diǎn)】（kHz）×【位深】（bit/采樣點(diǎn)）×【聲道數(shù)量】（一般為2）

在視頻中，比特率又常被稱為碼率。16kbps為可視電話質(zhì)量，128-384kpbs為商用視頻會(huì)議質(zhì)量，VCD一般為1.25Mbps，DVD為5Mkpbs，藍(lán)光光碟為40Mbps。 計(jì)算公式為：【碼率】(kbps)=【文件大小】(KB) * 8 / 【時(shí)間】(秒)。比如一部1G的電影，時(shí)長60分鐘，那么它的碼率則為 1 x 1024 x 1024 x 8 / 3600 = 2300Kbps/s。

1.1.3 幀率

幀，可以理解為一張采集到的靜止的畫面。幀率則指的是每秒顯示的幀數(shù)(Frames per Sercond, 簡稱FPS)。由于人眼的生理構(gòu)造，當(dāng)畫面的幀率高于16幀每秒(16fps)時(shí)，就會(huì)產(chǎn)生一個(gè)視覺停留，看起來就是一個(gè)連貫的畫面。比如我們看的動(dòng)畫片，也是同樣的原理，動(dòng)畫師將一個(gè)個(gè)場景畫出來，然后以一定的頻率切換，就產(chǎn)生了一個(gè)連貫的動(dòng)畫場景。一般來說，電影的幀率為23.97fps,電視為25fps。

1.1.4 分辨率

分辨率主要有2個(gè)分類：顯示分辨率跟像素分辨率。顯示分辨率指顯示器能顯示多少像素。像素分辨率指圖像單位英寸中包含的像素點(diǎn)數(shù)量。 描述分辨率的單位有：（dpi點(diǎn)每英寸）、lpi（線每英寸）和ppi（像素每英寸）。lpi是描述光學(xué)分辨率的尺度的，與dpi/ppi含義不同。dpi一般用于印刷行業(yè)較多，而ppi常見于計(jì)算機(jī)領(lǐng)域。
常見的分辨率尺寸：
DV: 480 x 720
720P: 720 x 1280
1080P: 1080 x 1920
2K: 1152 x 2048
4k: 2160 x 4096

1.2 音視頻播放流程

整個(gè)音視頻播放的流程，可以拆解為下面幾個(gè)主要流程：音視頻采集->前處理->音視頻編碼->音視頻處理/分發(fā)->音視頻解碼->后處理->渲染、播放。那么，音視頻流在整個(gè)上下行鏈路中，具體有哪些流程，每一步具體做了什么？我們常見的直播美顏，濾鏡，是在哪一步流程中處理的？下面會(huì)一一詳細(xì)展開講解。

1.2.1 上行和下行

直播場景針對(duì)音視頻流的來源，我們一般會(huì)分為上行以及下行，上行指的是音視頻采集端將畫面通過采集設(shè)備（攝像頭，麥克風(fēng)）采集后，通過編碼后上行到 server，一般我們稱主播端為上行端。下行指上行的視頻流經(jīng)過在server處理或者轉(zhuǎn)發(fā)后，傳輸?shù)?CDN 或者觀眾端。

1.2.2 音視頻采集

這一過程主要是利用攝像頭/麥克風(fēng)去分別捕獲圖像/聲音信號(hào)，并將聲音、圖像從物理信號(hào)轉(zhuǎn)化為數(shù)字信號(hào)。拿視頻來說，如果設(shè)置了攝像頭分辨率為640×480，幀率為30幀/s，那么每個(gè)畫面大小約為50kb左右，那么攝像頭每秒采集到的數(shù)據(jù)轉(zhuǎn)化為數(shù)字信號(hào)后的比特率則為：50×30/s＝1500kbps＝1.5Mbps。

1.2.3 前處理

前處理介于采集以及編碼中間，按照類型劃分可以分為音頻前處理和視頻前處理，音頻前處理包括降噪、回音消除、人聲檢測、自動(dòng)增益等，視頻前處理包括美顏、磨皮、設(shè)置對(duì)比度、鏡像、水印等。一般來說，前處理都是在上行方客戶端完成的，因?yàn)槠湫枰妮^大的cpu資源，放在server端成本較大，性能不佳。

1.2.4 音視頻編碼

前面提到的音視頻采集后的音視頻流為裸碼流，即沒有經(jīng)過編碼壓縮處理的數(shù)據(jù)。這里再舉個(gè)例子，例如一個(gè)例子，一個(gè)720p(1280x720)，每秒30幀，60分鐘的電影，其占用磁盤大小為：12Bx1280x720x30x60x100 = 1.9T。如果不經(jīng)過壓縮，傳輸這個(gè)視頻的時(shí)間無疑將非常漫長，以電信100M寬帶，大概需要下載43小時(shí)。所以需要對(duì)原始視頻裸碼流進(jìn)行壓縮，采用的手段就是音視頻的編碼，而編碼的目的就是壓縮。
視頻編碼通常都是有損壓縮，目標(biāo)是降低一點(diǎn)清晰度的同時(shí)讓體積得到大大的減少，降低的清晰度能達(dá)到對(duì)人眼不可察覺或者幾乎無法分辨的水平。主要是方法是去除視頻里面的冗余信息，對(duì)于很多不是劇烈變化的場面，相鄰幀里面有很多重復(fù)信息，通過幀間預(yù)測等方法分析和去除，而幀內(nèi)預(yù)測可去掉同個(gè)幀里的重復(fù)信息，還有對(duì)畫面觀眾比較關(guān)注的前景部分高碼率編碼，而對(duì)背景部分做低碼率編碼，等等，這些取決于不同的壓縮算法。而解碼相對(duì)的就是解壓縮，還原成原始像素。常見的音視頻編解碼算法前面-章節(jié)已經(jīng)提到，這里就不展開細(xì)講了。

1.2.5 音視頻處理/分發(fā)

編碼后的音視頻數(shù)據(jù)通過某種傳輸協(xié)議(rtp,rtmp,rtsp等)上行到音視頻處理/分發(fā)的服務(wù)器，服務(wù)器可以根據(jù)具體的業(yè)務(wù)場景去實(shí)現(xiàn)多路音視頻的混流，轉(zhuǎn)碼，轉(zhuǎn)協(xié)議，轉(zhuǎn)發(fā)給具體的下行段。

1.2.6 音視頻解碼

當(dāng)觀眾接收到音視頻流時(shí)，瀏覽器是怎么把數(shù)據(jù)渲染成畫面跟播放出聲音的呢？ 上面是chrome內(nèi)核Chromium對(duì)接收到的音視頻數(shù)據(jù)進(jìn)行處理的流程。當(dāng)我們用HTML5播放視頻，通過初始化一個(gè)video標(biāo)簽創(chuàng)建一個(gè)DOM對(duì)下，它會(huì)實(shí)例化一個(gè)WebMediaPlayer,這個(gè)Player通過去請求多媒體數(shù)據(jù)，進(jìn)行解協(xié)議，就是圖中Internet到DataSource這個(gè)過程，得到音視頻的封裝格式，比如MP4,FLV等。接著再解封裝，這個(gè)過程一般稱為demux，拿到音視頻軌。拿視頻軌道來說，里面分別會(huì)有I幀,B幀(可能沒有),P幀。其中I幀是關(guān)鍵幀（I幀，Intra frame），包含了該幀的完整圖象信息。另一些幀只是記錄和參考幀的差異，叫幀間預(yù)測幀（Inter frame），所以比較小，預(yù)測幀有前向預(yù)測幀P幀和雙向預(yù)測幀B幀，P幀是參考前面解碼過的圖像，而B幀參考雙向的。用對(duì)應(yīng)的音視頻解碼器去解碼，得到原始數(shù)據(jù)。這里解demux使用的是chrome里面內(nèi)置的開源第三方FFmpeg解碼模塊。

1.2.7 渲染、播放

把解碼后的數(shù)據(jù)傳給相應(yīng)的渲染器對(duì)象進(jìn)行渲染繪制，最后讓video標(biāo)簽去顯示或者聲卡進(jìn)行播放。

1.3 音視頻封裝格式

導(dǎo)語：所謂視頻的封裝，就是將編碼好的音頻、視頻、或者是字幕、腳本之類的文件根據(jù)相應(yīng)的規(guī)范組合在一起，從而生成一個(gè)封裝格式的文件。

1.3.1 封裝格式

封裝格式，其是將已經(jīng)編碼壓縮好的視頻軌和音頻軌按照一定的格式放到一個(gè)文件中，也就是說僅僅是一個(gè)外殼，或者大家把它當(dāng)成是一個(gè)可組合視頻和音頻的容器。 說得形象一點(diǎn)，視頻相當(dāng)于米飯，而音頻相當(dāng)于菜，此時(shí)封裝格式就是一個(gè)碗，可用來盛放飯菜的容器。當(dāng)然不同的碗（封裝格式）有不同特點(diǎn)。下面是一些常見的封裝格式。其實(shí)不然，試想一下，有的菜，例如排骨，比較大，碗放不下，得換鍋。有的飯比較燙，也不能放在塑料的容器里，當(dāng)然個(gè)人喜好也有一定關(guān)系。所以容器的選擇，基本在于其對(duì)視頻/音頻兼容性，以及適合范圍。

AVI容器（后綴為.AVI）

AVI是微軟1992年推出用于對(duì)抗蘋果Quicktime的技術(shù)，盡管國際學(xué)術(shù)界公認(rèn)AVI已經(jīng)屬于被淘汰的技術(shù)，但是由于windows的通用性，和簡單易懂的開發(fā)API，還在被廣泛使用。

這種視頻格式的優(yōu)點(diǎn)是圖像質(zhì)量好。由于無損AVI可以保存alpha通道，經(jīng)常被我們使用。缺點(diǎn)太多，體積過于龐大，而且更加糟糕的是壓縮標(biāo)準(zhǔn)不統(tǒng)一，最普遍的現(xiàn)象就是高版本W(wǎng)indows媒體播放器播放不了采用早期編碼編輯的AVI格式視頻，而低版本W(wǎng)indows媒體播放器又播放不了采用最新編碼編輯的AVI格式視頻，所以我們在進(jìn)行一些AVI格式的視頻播放時(shí)常會(huì)出現(xiàn)由于問題而造成的視頻不能播放或即使能夠播放，但存在不能調(diào)節(jié)播放進(jìn)度和播放時(shí)只有聲音沒有圖像等一些莫名其妙的問題。

Matroska格式（后綴為.MKV）

是一種新的多媒體封裝格式，這個(gè)封裝格式可把多種不同編碼的視頻及16條或以上不同格式的音頻和語言不同的字幕封裝到一個(gè)Matroska Media檔內(nèi)。它也是其中一種開放源代碼的多媒體封裝格式。Matroska同時(shí)還可以提供非常好的交互功能，而且比MPEG的方便、強(qiáng)大。

QuickTime File Format格式（后綴為.MOV）

美國Apple公司開發(fā)的一種視頻格式，默認(rèn)的播放器是蘋果的QuickTime。

具有較高的壓縮比率和較完美的視頻清晰度等特點(diǎn)，并可以保存alpha通道。大家可能注意到了，每次安裝EDIUS，我們都要安裝蘋果公司推出的QuickTime。安裝其目的就是為了支持JPG格式圖像和MOV視頻格式導(dǎo)入。

MPEG格式

MPEG格式（文件后綴可以是 .MPG .MPEG .MPE .DAT .VOB .ASF .3GP .MP4等）：它的英文全稱為 Moving Picture Experts Group，是一個(gè)國際標(biāo)準(zhǔn)化組織（ISO）認(rèn)可的媒體封裝形式，受到大部份機(jī)器的支持。其存儲(chǔ)方式多樣，可以適應(yīng)不同的應(yīng)用環(huán)境。MPEG的控制功能豐富，可以有多個(gè)視頻（即角度）、音軌、字幕（位圖字幕）等等。

WMV格式（后綴為.WMV .ASF）

它的英文全稱為Windows Media Video，也是微軟推出的一種采用獨(dú)立編碼方式并且可以直接在網(wǎng)上實(shí)時(shí)觀看視頻節(jié)目的文件壓縮格式。

WMV格式的主要優(yōu)點(diǎn)包括：本地或網(wǎng)絡(luò)回放,豐富的流間關(guān)系以及擴(kuò)展性等。WMV格式需要在網(wǎng)站上播放，需要安裝Windows Media Player（簡稱WMP），很不方便，現(xiàn)在已經(jīng)幾乎沒有網(wǎng)站采用了。

Flash Video格式（后綴為.FLV）

由Adobe Flash延伸出來的的一種流行網(wǎng)絡(luò)視頻封裝格式。隨著視頻網(wǎng)站的豐富，這個(gè)格式已經(jīng)非常普及。

1.4 音視頻編解碼

音視頻在網(wǎng)絡(luò)中傳播，主要分為如下幾個(gè)階段：錄制-編碼-傳輸-解碼-播放，音視頻編解碼發(fā)揮這不可忽視的作用，能夠優(yōu)化數(shù)據(jù)包大小，通常通過媒體采集設(shè)備采集的音視頻頻數(shù)據(jù)被編碼后，可以極大的壓縮數(shù)據(jù)，并且畫質(zhì)影響不大，通常用戶對(duì)直播畫面實(shí)時(shí)性要求很高，了解編碼底層原理有助于優(yōu)化直播流暢性。本節(jié)主要介紹常見的音視頻編解碼格式。

1.4.1 常見音頻編碼格式

音頻編碼是為了將 PCM 音頻采樣數(shù)據(jù)轉(zhuǎn)換為音頻碼流， 優(yōu)化網(wǎng)絡(luò)傳輸效率。常見的格式有：FLAC、APE、WAV、Opus、MP3、WMA、AAC。

FLAC、APE、WAV 是屬于無損編碼格式，壓縮率低，通常用于音質(zhì)要求較高的音樂等內(nèi)容; Opus、MP3、WMA、AAC 屬于有損壓縮格式，壓縮率高利于網(wǎng)絡(luò)傳輸; 其中 Opus、OGG 屬于完全免費(fèi)開源的編碼格式。不同的編碼格式特點(diǎn)也不盡相同，不同編碼面向的使用場景不同，沒有絕對(duì)的優(yōu)劣。

下面詳細(xì)介紹常見的編碼格式：
1, FLAC

FLAC 全稱 Free Lossless Audio Codec，中文直譯為自由無損音頻壓縮編碼。無損也就是說當(dāng)你將從音頻 CD 上讀取的音頻數(shù)據(jù)文件壓縮成 FLAC 格式后，你還可以再將 FLAC 格式的文件還原，而還原后的音頻文件與壓縮前的一模一樣，沒有任何損失。

FLAC 是一款的自由音頻壓縮編碼，其特點(diǎn)是可以對(duì)音頻文件無損壓縮。不同于其他有損壓縮編碼，如 MP3 、AAC，壓縮后不會(huì)有任何音質(zhì)損失，現(xiàn)在已被很多軟件及硬件音頻產(chǎn)品所支持，很多流行的音樂播放器默認(rèn)的無損音頻格式都是 FLAC。

特點(diǎn)：無損壓縮格式，體積較大，但是兼容性好，編碼速度快，播放器支持廣。

2, APE

APE 是一種常見的無損音頻壓縮編碼格式，APE 是其編碼后的文件擴(kuò)展名，該編碼格式的名稱是 Monkey's Audio。

Monkey's Audio 壓縮比高于其他常見的無損音頻壓縮格式，約在 55%上下，但編解碼速度略慢。在搜尋回放位置時(shí)，如果文件壓縮比過高，在配備較差的計(jì)算機(jī)會(huì)有延遲的現(xiàn)象。另外，由于它沒有提供錯(cuò)誤處理的功能，若發(fā)生文件損壞，損壞位置之后的數(shù)據(jù)有可能會(huì)丟失。

Monkey's Audio 是開放源代碼的免費(fèi)軟件，但因其授權(quán)協(xié)議并非自由軟件而是準(zhǔn)自由軟件（Semi-free Software）而受到排擠。因?yàn)檫@意味著許多基于 GNU/Linux 的 Linux 發(fā)行包或是其他只能基于自由軟件的操作系統(tǒng)不能將其收入。較之其他使用更自由的許可證的無損音頻編碼器（如 FLAC），受其他軟件的支持也更少。

特點(diǎn)：無損壓縮格式，其體積比其它無損壓縮格式較小，編碼速度偏慢。

3, WAV

WAV 全稱 Waveform Audio File Format，是微軟公司開發(fā)的一種聲音文件格式，也叫波形聲音文件，是最早的數(shù)字音頻格式，被 Windows 平臺(tái)及其應(yīng)用程序廣泛支持。

WAV 格式支持許多壓縮算法，支持多種音頻位數(shù)、采樣頻率和聲道，采用 44.1kHz 的采樣頻率，16 位量化位數(shù)，因此 WAV 的音質(zhì)與 CD 相差無幾，但 WAV 格式對(duì)存儲(chǔ)空間需求太大不便于交流和傳播。

特點(diǎn)：無損壓縮格式，體積十分大。

4,Opus

Opus 是一個(gè)有損聲音編碼的格式，由 Xiph.Org 基金會(huì)開發(fā)，之后由 IETF 互聯(lián)網(wǎng)工程任務(wù)組進(jìn)行標(biāo)準(zhǔn)化，適用于網(wǎng)上低延遲的即時(shí)聲音傳輸，標(biāo)準(zhǔn)格式定義于 RFC 6716 文件。Opus 格式是一個(gè)開放格式，使用上沒有任何專利或限制。

Opus 集成了兩種聲音編碼的技術(shù)：以語音編碼為導(dǎo)向的 SILK 和低延遲的 CELT。Opus 可以無縫調(diào)節(jié)高低比特率。在編碼器內(nèi)部它在較低比特率時(shí)使用線性預(yù)測編碼在高比特率時(shí)候使用變換編碼（在高低比特率交界處也使用兩者結(jié)合的編碼方式）。Opus 具有非常低的算法延遲（默認(rèn)為 22.5 ms），非常適合用于低延遲語音通話的編碼，像是網(wǎng)上上的即時(shí)聲音流、即時(shí)同步聲音旁白等等，此外 Opus 也可以透過降低編碼碼率，達(dá)成更低的算法延遲，最低可以到 5 ms。在多個(gè)聽覺盲測中，Opus 都比 MP3、AAC 等常見格式，有更低的延遲和更好的聲音壓縮率。

在 WebRTC 實(shí)現(xiàn)中，強(qiáng)制要求支持 Opus，也是其默認(rèn)的音頻編碼格式。

特點(diǎn)：有損壓縮;可動(dòng)態(tài)調(diào)節(jié)比特率，音頻帶寬和幀大小;開放免費(fèi)、沒有專利限制。

5, MP3

MP3 的全稱是 Moving Picture Experts Group Audio Layer III。由于這種壓縮方式的全稱叫 MPEG Audio Layer3，所以簡稱為 MP3。

MP3 是利用 MPEG Audio Layer 3 的技術(shù)，將音樂以 1:10 甚至 1:12 的壓縮率，壓縮成容量較小的 file，換句話說，能夠在音質(zhì)丟失很小的情況下把文件壓縮到更小的程度。而且還非常好的保持了原來的音質(zhì)。

正是因?yàn)?MP3 體積小，音質(zhì)高的特點(diǎn)使得 MP3 格式幾乎成為網(wǎng)上音樂的代名詞。

特點(diǎn)：有損壓縮，壓縮率高，文件體積小，最高比特率 320K

6, WMA

WMA 的全稱是 Windows Media Audio，是微軟力開發(fā)的一種音頻編碼格式。一般情況下相同音質(zhì)的 WMA 和 MP3 音頻，前者文件體積較小，并且可以通過 DRM（Digital Rights Management）方案加入防止拷貝，或者加入限制播放時(shí)間和播放次數(shù)，甚至是播放機(jī)器的限制，可有力地防止盜版。

特點(diǎn)：支持 DRM 防盜版，相比 MP3 格式壓縮率更高

7, AAC

AAC 全稱 Advanced Audio Coding，是一種基于 MPEG-2 的有損數(shù)字音頻壓縮的專利音頻編碼標(biāo)準(zhǔn)，由 Fraunhofer IIS、杜比實(shí)驗(yàn)室、AT&T、Sony、Nokia 等公司共同開發(fā)。MPEG-4 標(biāo)準(zhǔn) 出臺(tái)后，在原本的基礎(chǔ)上加上了 PNS（Perceptual Noise Substitution）等技術(shù)，并提供了多種擴(kuò)展工具。為了區(qū)別于傳統(tǒng)的 MPEG-2 AAC 又稱為 MPEG-4 AAC。其作為 MP3 的后繼者而被設(shè)計(jì)出來，在相同的位元率之下，AAC 相較于 MP3 通?？梢赃_(dá)到更好的聲音質(zhì)量。

AAC 提供了低至 8 kHz 高至 96 kHz 的多種采樣率、更高的比特深度(8, 16, 24, 32 bit)，并且支持 1 到 48 之間的任何聲道數(shù)

特點(diǎn)：目前最好的有損格式之一，壓縮率高

1.4.2 常見視頻編碼格式

視頻編碼主要是為了將視頻像素?cái)?shù)據(jù)壓縮成視頻碼流，以降低視頻的大小，從而方便網(wǎng)絡(luò)傳輸和存儲(chǔ)。常見的格式有：MPEG-2、H.264、H.265、VP8、VP9。

1, MPEG-2

MPEG-2 是 MPEG 工作組于 1994 年發(fā)布的視頻和音頻壓縮國際標(biāo)準(zhǔn)，視頻編碼是 MPEG-2 標(biāo)準(zhǔn)的第二部分，其視頻通常包含多個(gè) GOP(Group Of Pictures)，每一個(gè) GOP 包含多個(gè)幀（frame）。幀類型（frame type）通常包括 I-幀（I-frame）、P-幀（P-frame）和 B-幀（B-frame）。其中 I-幀采用幀內(nèi)編碼，P-幀采用前向估計(jì)，B-幀采用雙向估計(jì)。通常 I 幀被稱為關(guān)鍵幀，包含了完整的一幀圖像。

I 幀圖像采用幀內(nèi)編碼方式，即只利用了單幀圖像內(nèi)的空間相關(guān)性，而沒有利用時(shí)間相關(guān)性。I 幀使用幀內(nèi)壓縮，不使用運(yùn)動(dòng)補(bǔ)償，由于 I 幀不依賴其它幀，所以是隨機(jī)存取的入點(diǎn)，同時(shí)是解碼的基準(zhǔn)幀。I 幀主要用于接收機(jī)的初始化和信道的獲取，以及節(jié)目的切換和插入，I 幀圖像的壓縮倍數(shù)相對(duì)較低。I 幀圖像是周期性出現(xiàn)在圖像序列中的，出現(xiàn)頻率可由編碼器選擇。

P 幀和 B 幀圖像采用幀間編碼方式，即同時(shí)利用了空間和時(shí)間上的相關(guān)性。P 幀圖像只采用前向時(shí)間預(yù)測，可以提高壓縮效率和圖像質(zhì)量。P 幀圖像中可以包含幀內(nèi)編碼的部分，即 P 幀中的每一個(gè)宏塊可以是前向預(yù)測，也可以是幀內(nèi)編碼。

B 幀圖像采用雙向時(shí)間預(yù)測，可以大大提高壓縮倍數(shù)。值得注意的是，由于 B 幀圖像采用了未來幀作為參考，因此 MPEG-2 編碼碼流中圖像幀的傳輸順序和顯示順序是不同的。

2, H.264

H.264，又稱為 MPEG-4 第 10 部分，高級(jí)視頻編碼（英語：MPEG-4 Part 10, Advanced Video Coding，縮寫為 MPEG-4 AVC）是一種面向塊，基于運(yùn)動(dòng)補(bǔ)償?shù)囊曨l編碼標(biāo)準(zhǔn) 。到 2014 年，它已經(jīng)成為高精度視頻錄制、壓縮和發(fā)布的最常用格式之一。第一版標(biāo)準(zhǔn)的最終草案于 2003 年 5 月完成。該編碼標(biāo)準(zhǔn)被廣泛用于網(wǎng)絡(luò)流媒體數(shù)據(jù)傳輸，在國內(nèi)流媒體資源普遍采用該編碼格式。

3, H.265

高效率視頻編碼（High Efficiency Video Coding，簡稱 HEVC），又稱為 H.265 和 MPEG-H 第 2 部分，是一種視頻壓縮標(biāo)準(zhǔn)，被視為是 ITU-T H.264/MPEG-4 AVC 標(biāo)準(zhǔn)的繼任者。2004 年開始由 MPEG(ISO/IEC Moving Picture Experts Group)和 VCEG(ITU-T Video Coding Experts Group)作為 MPEG-H Part 2 或稱作 ITU-T H.265 開始制定。第一版的 HEVC/H.265 視頻壓縮標(biāo)準(zhǔn)在 2013 年 4 月 13 日被接受為國際電信聯(lián)盟（ITU-T）的正式標(biāo)準(zhǔn)。

HEVC 被認(rèn)為不僅提升視頻質(zhì)量，同時(shí)也能達(dá)到 H.264/MPEG-4 AVC 兩倍之壓縮率（等同于同樣畫面質(zhì)量下位元率減少到了 50%），可支持 4K 清晰度甚至到超高清電視（UHDTV），最高清晰度可達(dá)到 8192×4320（8K 清晰度）。

4, VP8

是開放免費(fèi)的編碼格式，是 Google 收購 On2 公司之后獲得的軟件，旨在提供免費(fèi)的編碼格式提供給 HTML5 使用，通常被封裝在 webM 容器中傳播。該編碼很少有公司采用。

5, VP9

VP9 是谷歌公司為了替換老舊的 VP8 視頻編碼格式并與動(dòng)態(tài)專家圖像組（MPEG）主導(dǎo)的高效率視頻編碼（H.265/HEVC）競爭所開發(fā)的免費(fèi)、開源的視頻編碼格式。VP9 一般與 Opus 音頻編碼一起以 WebM 格式封裝

相比于 H.265，許多瀏覽器都支持 VP9 視頻格式，截止 2018 年 6 月，約有 4/5 的瀏覽器（包括移動(dòng)設(shè)備）支持 WebM 封裝容器和 VP9 視頻編碼，例如: Chrome、Microsoft Edge、Firefox、Opera 等瀏覽器都內(nèi)置了 VP9 解碼器，可在 HTML5 播放器中播放 VP9 視頻格式。Windows 10 操作系統(tǒng)也內(nèi)置了 WebM 分離器和 VP9 解碼器。

1.5 音視頻傳輸協(xié)議

導(dǎo)語：服務(wù)端（例如主播的直播畫面）的音視頻，如何傳輸?shù)接^眾（用戶端），這之間相關(guān)傳輸細(xì)節(jié)的溝通（傳輸?shù)木幗獯a格式，傳輸方式等）其是音視頻傳輸協(xié)議來定義。

目前在網(wǎng)絡(luò)上傳輸音/視頻（英文縮寫A/V）等多媒體信息主要有下載和流式傳輸兩種方案。

下載式傳輸

我們知道音視頻文件普通體積都比較大，在網(wǎng)絡(luò)帶寬的限制，下載常常需要耗費(fèi)花較長的時(shí)間。所以這種處理方法延遲也很大。并且用戶需要等到把整個(gè)音視頻文件全部下載完后才能使用播放器進(jìn)行觀看。

流式傳輸（流媒體協(xié)議）

流式傳輸時(shí)，聲音、影像或動(dòng)畫等時(shí)基媒體由音視頻服務(wù)器向用戶計(jì)算機(jī)的連續(xù)、實(shí)時(shí)傳送，用戶不必等到整個(gè)文件全部下載完畢，而只需經(jīng)過幾秒或十?dāng)?shù)秒的啟動(dòng)延時(shí)即可進(jìn)行觀看。當(dāng)聲音等時(shí)基媒體在客戶機(jī)上播放時(shí)，文件的剩余部分將在后臺(tái)從服務(wù)器內(nèi)繼續(xù)下載。流式不僅使啟動(dòng)延時(shí)成十倍、百倍地縮短，而且不需要太大的緩存容量。流式傳輸避免了用戶必須等待整個(gè)文件全部從 Internet 上下載才能觀看的缺點(diǎn)。而定義音視頻數(shù)據(jù)如何流式傳輸?shù)膭t是流媒體傳輸協(xié)議。

RTP/RTCP/RTSP 基礎(chǔ)協(xié)議族

本協(xié)議族是最早的視頻傳輸協(xié)議。其中RTSP協(xié)議用于視頻點(diǎn)播的會(huì)話控制，例如發(fā)起點(diǎn)播請求的SETUP請求，進(jìn)行具體播放操作的PLAY、PAUSE請求，視頻的跳轉(zhuǎn)也是通過PLAY請求的參數(shù)支持的。而RTP協(xié)議用于具體的視頻數(shù)據(jù)流的傳輸。RTCP協(xié)議中的C是控制的意思，用于在視頻流數(shù)據(jù)之外，丟包或者碼率之類的控制。該協(xié)議族RTSP是建立在TCP之上的，RTP、RTCP建立在UDP之上。不過也可以通過interleave的方式，將RTP和RTSP一起在同一個(gè)TCP連接上傳輸。RTSP協(xié)議族，是最早被提出來的，因此很多考慮的地方，都還帶有早期的特征。比如使用UDP，是考慮到傳輸?shù)男剩约耙曨l協(xié)議本身對(duì)丟包就有一定的容忍度。但是UDP協(xié)議，顯然不能用于更大規(guī)模的網(wǎng)絡(luò)，而且復(fù)雜網(wǎng)絡(luò)下路由器的穿透也是問題。從視頻角度而言，RTSP協(xié)議族的優(yōu)勢，在于可以控制到視頻幀，因此可以承載實(shí)時(shí)性很高的應(yīng)用。這個(gè)優(yōu)點(diǎn)是相對(duì)于HTTP方式的最大優(yōu)點(diǎn)。H.323視頻會(huì)議協(xié)議，底層一般采用RTSP協(xié)議。RTSP協(xié)議族的復(fù)雜度主要集中在服務(wù)器端，因?yàn)榉?wù)器端需要parse視頻文件，seek到具體的視頻幀，而且可能還需要進(jìn)行倍速播放（就是老舊的DVD帶的那種2倍速，4倍速播放的功能），倍速播放功能是RTSP協(xié)議獨(dú)有的，其他視頻協(xié)議都無法支持。缺點(diǎn)，就是服務(wù)器端的復(fù)雜度也比較高，實(shí)現(xiàn)起來也比較復(fù)雜。

需要注意的是, WebRTC 音視頻傳輸就是基于 RTP 協(xié)議

RTMP

Time Messaging Protocol，實(shí)時(shí)消息傳送協(xié)議)RTMP是Adobe Systems公司為Flash播放器和服務(wù)器之間音頻、視頻和數(shù)據(jù)傳輸開發(fā)的開放協(xié)議。它有三種變種：1、工作在TCP之上的明文協(xié)議，使用端口1935；2、RTMPT封裝在HTTP請求之中，可穿越防火墻；3、RTMPS類似RTMPT，但使用的是HTTPS連接；RTMP協(xié)議是被Flash用于對(duì)象、視頻、音頻的傳輸。這個(gè)協(xié)議建立在TCP協(xié)議或者輪詢HTTP協(xié)議之上。RTMP協(xié)議就像一個(gè)用來裝數(shù)據(jù)包的容器，這些數(shù)據(jù)既可以是AMF格式的數(shù)據(jù)，也可以是FLV中的視音頻數(shù)據(jù)。一個(gè)單一的連接可以通過不同的通道傳輸多路網(wǎng)絡(luò)流，這些通道中的包都是按照固定大小的包傳輸?shù)摹?/p>

HLS

HTTP Live Streaming（HLS）是蘋果公司(Apple Inc.)實(shí)現(xiàn)的基于HTTP的流媒體傳輸協(xié)議，可實(shí)現(xiàn)流媒體的直播和點(diǎn)播，主要應(yīng)用在iOS系統(tǒng)，為iOS設(shè)備（如iPhone、iPad）提供音視頻直播和點(diǎn)播方案。HLS點(diǎn)播，基本上就是常見的分段HTTP點(diǎn)播，不同在于，它的分段非常小。

相對(duì)于常見的流媒體直播協(xié)議，例如RTMP協(xié)議、RTSP協(xié)議、MMS協(xié)議等，HLS直播最大的不同在于，直播客戶端獲取到的，并不是一個(gè)完整的數(shù)據(jù)流。HLS協(xié)議在服務(wù)器端將直播數(shù)據(jù)流存儲(chǔ)為連續(xù)的、很短時(shí)長的媒體文件（MPEG-TS格式），而客戶端則不斷的下載并播放這些小文件，因?yàn)榉?wù)器端總是會(huì)將最新的直播數(shù)據(jù)生成新的小文件，這樣客戶端只要不停的按順序播放從服務(wù)器獲取到的文件，就實(shí)現(xiàn)了直播。由此可見，基本上可以認(rèn)為，HLS是以點(diǎn)播的技術(shù)方式來實(shí)現(xiàn)直播。由于數(shù)據(jù)通過HTTP協(xié)議傳輸，所以完全不用考慮防火墻或者代理的問題，而且分段文件的時(shí)長很短，客戶端可以很快的選擇和切換碼率，以適應(yīng)不同帶寬條件下的播放。不過HLS的這種技術(shù)特點(diǎn)，決定了它的延遲一般總是會(huì)高于普通的流媒體直播協(xié)議?！?/p>

總結(jié)

若想進(jìn)入Web音視頻領(lǐng)域，以上的基本概念必須都要了解，每個(gè)概念都可以單獨(dú)拎出來往很深入的方向去研究。隨著5G時(shí)代的到來，相信未來的Web將有更加廣泛的音視頻應(yīng)用場景，掌握音視頻知識(shí)，為未來做好準(zhǔn)備。未來的前端開發(fā)不單知識(shí)HTML, JavaScript，相信音視頻相關(guān)的開發(fā)也是必須掌握的技能。