基礎(chǔ)知識

音頻基礎(chǔ)

聲音轉(zhuǎn)數(shù)字信號

音頻基礎(chǔ)知識及 PCM 技術(shù)詳解

聲音的本質(zhì)是一種能量波。音調(diào)，由聲音的頻率決定。音量，由振幅和人離聲源的距離決定。音色，由波形決定。從聲音到數(shù)字信號，宏觀上包括三個步驟：

1. 聲波通過空氣傳播到麥克風(fēng)的振膜。
2. 振膜隨空氣抖動的振幅大小產(chǎn)生相應(yīng)的電學(xué)信號，即模擬信號（Analogue Signal）。
3. 通過模數(shù)轉(zhuǎn)換器 ADC 將模擬信號轉(zhuǎn)換成數(shù)字信號（Digital Signal）。

數(shù)字音頻的 A/D 轉(zhuǎn)換涵蓋三個過程：采樣、量化以及編碼。PCM（Pulse Code Modulation）脈沖編碼調(diào)制屬于數(shù)字通信的編碼方式之一，它將一個時間連續(xù)且取值連續(xù)的模擬信號轉(zhuǎn)化為時間離散、取值離散的數(shù)字信號，而后在信道中進(jìn)行傳輸。

麥克風(fēng)收集到的音源在本質(zhì)上屬于模擬信號。采樣過程是將時間連續(xù)的模擬信號轉(zhuǎn)變?yōu)闀r間離散、幅度連續(xù)的抽樣信號，從而在時間軸上實(shí)現(xiàn)對信號的數(shù)字化操作。量化則是把時間離散且幅度連續(xù)的抽樣信號進(jìn)一步轉(zhuǎn)換為時間離散、幅度離散的數(shù)字信號，在幅度軸上完成對信號的數(shù)字化處理。編碼是把量化后的信號進(jìn)行編碼，形成由多位二進(jìn)制碼組成的碼組來表示抽樣值，以此完成從模擬信號到數(shù)字信號的轉(zhuǎn)換，即按照特定格式記錄采樣和量化后的數(shù)字信息。編碼后的二進(jìn)制碼組通過數(shù)字信道進(jìn)行傳輸，在接收端，經(jīng)過譯碼和濾波等操作，最終還原為模擬信號。

模數(shù)轉(zhuǎn)換本質(zhì)上就是把連續(xù)的模擬信號轉(zhuǎn)換為成比例的、時間離散且幅度離散的數(shù)字信號。人耳所能感知到的聲音頻率范圍處于 20Hz 至 20KHz 之間。根據(jù)香農(nóng)采樣定律，為了能夠不失真地恢復(fù)模擬信號，采樣頻率應(yīng)大于等于模擬信號頻譜中最高頻率的兩倍。正因如此，音頻文件的采樣率通常在 40KHz 至 50KHz 左右。

音頻壓縮

編碼之 AAC 解析

理論上任何數(shù)字音頻都無法做到完全還原模擬信號。而 PCM 編碼作為模擬信號轉(zhuǎn)換為數(shù)字信號時的原始編碼，代表著數(shù)字音頻的最佳保真水平，因此被約定為 “無損編碼”。音頻壓縮是對 PCM 編碼進(jìn)行的二次編碼，其目的在于減小原始 PCM 編碼的存儲體積。音頻二次編碼分為兩類，即有損編碼和無損編碼，也稱為有損壓縮和無損壓縮。其中，無損意味著與 PCM 編碼相對比，音質(zhì)完全相同。而有損則是相較于 PCM 編碼，會損失一部分音頻質(zhì)量。

無損壓縮是指將數(shù)據(jù)進(jìn)行壓縮，通過解碼能夠還原成與原始數(shù)據(jù)完全一模一樣的數(shù)據(jù)。例如 ALAC、APE、FLAC 等都屬于無損音頻格式。

有損壓縮是通過消除冗余信息，只保留人耳能感知的聲音頻率在 20Hz-20000Hz 以內(nèi)的數(shù)據(jù)。例如 MP3、AAC、OGG、WMA 等都屬于有損音頻格式。

人耳能感知的聲音信號頻率范圍為 20Hz～20KHz，在此范圍之外的頻率信號均可視為冗余信息。人耳聽覺還具有生理和心理聲學(xué)現(xiàn)象，當(dāng)強(qiáng)音信號與弱音信號同時存在時，弱音信號會被強(qiáng)音信號所屏蔽，此時弱音信號就可以視為冗余信息。這便是人耳聽覺的掩蔽效應(yīng)，主要表現(xiàn)在頻譜掩蔽效應(yīng)和時域掩蔽效應(yīng)。在各大音樂平臺的無損音質(zhì)和高品音質(zhì)對應(yīng)的就是無損壓縮和有損壓縮，無損音質(zhì)具有更高的保真度和還原度，適合專業(yè)音樂制作、高端音頻設(shè)備等領(lǐng)域；無損壓縮具有更高的碼率和傳輸效率，適合大多數(shù)非專業(yè)的普通聽眾。通常情況下，高品音質(zhì)的存儲空間一般只有無損音質(zhì)的三分之一。

視頻基礎(chǔ)

編碼原理

• 理解視頻編解碼技術(shù)
• 音視頻h264編碼介紹

我們可以將視頻定義為在單位時間內(nèi)連續(xù)的 n 幀，這可以視作一個新的維度，n 即為幀率，若單位時間為秒，則等同于 FPS（每秒幀數(shù) Frames Per Second）。

播放一段視頻時，每秒所需的數(shù)據(jù)量便是它的比特率（也就是常說的碼率）。比特率決定視頻的清晰度和流暢度，比特率越高，視頻的質(zhì)量就越好，但同時也需要更多的存儲空間和帶寬來傳輸。在選擇視頻的比特率時，需要根據(jù)實(shí)際情況進(jìn)行權(quán)衡，以達(dá)到最佳的觀看效果。

比特率 = 寬 * 高 * 顏色深度 * 幀每秒

一個相當(dāng)?shù)湫偷?30 分鐘視頻會議需要大約 447.9 GB 的存儲空間，而一部 2 小時的電影需要幾乎 1.79 TB（即 1790 GB）的空間。

單幀全彩色高清 1920×1080 視頻（每像素 4 字節(jié)）為 8294400 字節(jié)，在幀率 30 的情況下，每秒高清視頻將占用 237 MB。

在這種前提下，1 分鐘的資源就需要 13.9 GB 的存儲空間，30 分鐘視頻會議需要大約 417 GB 的存儲空間，而一部 2 小時的電影需要幾乎 1.63 TB的存儲空間。顯然這么大的數(shù)據(jù)是無法接受的，因此不得不對視頻資源進(jìn)行壓縮，即編碼。

視頻編碼的核心思想在于去除冗余信息，而這些冗余信息主要包含以下幾個方面：

• 空間冗余：圖像相鄰像素之間有較強(qiáng)的相關(guān)性。例如，在一幅風(fēng)景圖像中，同一片天空區(qū)域的相鄰像素顏色和亮度可能非常接近，這就形成了空間冗余。
• 時間冗余：視頻序列的相鄰圖像之間內(nèi)容相似。例如，在一個人物講話的視頻中，連續(xù)的幾幀畫面中人物的姿勢和背景可能變化不大，這就產(chǎn)生了時間冗余。
• 編碼冗余：不同的像素值出現(xiàn)的概率并不相同。如果采用固定長度的編碼方式，對于出現(xiàn)概率高的像素值和出現(xiàn)概率低的像素值分配相同的編碼長度，就會造成編碼冗余。
• 視覺冗余：人的視覺系統(tǒng)對某些細(xì)節(jié)并不敏感。例如，在一幅圖像中，細(xì)微的顏色變化或者一些高頻的紋理可能不會被人眼輕易察覺，這些部分的信息可以在一定程度上進(jìn)行壓縮而不影響整體的視覺效果。
• 知識冗余：一些規(guī)律性的結(jié)構(gòu)可以由先驗(yàn)知識和背景知識得到。例如，在一幅建筑物的圖像中，我們可以根據(jù)建筑的結(jié)構(gòu)特點(diǎn)和常見的設(shè)計規(guī)律來預(yù)測某些部分的像素值，從而減少需要存儲的信息量。

視頻壓縮

H.264&H.265視頻編碼原理介紹與對比

H.264/AVC 采用的核心算法是幀內(nèi)壓縮和幀間壓縮，幀內(nèi)壓縮是生成 I 幀的算法，幀間壓縮是生成 B 幀和 P 幀的算法。

幀內(nèi)壓縮，亦稱為空間壓縮。在對一幀圖像進(jìn)行壓縮時，僅僅考慮本幀的數(shù)據(jù)，而不涉及相鄰幀之間的冗余信息，這在實(shí)際操作中與靜態(tài)圖像壓縮較為相似。幀內(nèi)通常采用有損壓縮算法，因?yàn)閹瑑?nèi)壓縮是對一個完整的圖像進(jìn)行編碼，所以能夠獨(dú)立地進(jìn)行解碼和顯示。不過，幀內(nèi)壓縮一般難以達(dá)到很高的壓縮率，其效果與編碼 JPEG 大致相當(dāng)。幀間壓縮的原理在于：相鄰的幾幀數(shù)據(jù)具有很大的相關(guān)性，或者說前后兩幀的信息變化非常小。也就是說，連續(xù)的視頻中其相鄰幀之間存在冗余信息。根據(jù)這一特性，對相鄰幀之間的冗余量進(jìn)行壓縮，就能夠進(jìn)一步提高壓縮量，減小壓縮比。

幀間壓縮，亦稱為時間壓縮。其主要通過對時間軸上不同幀之間的數(shù)據(jù)進(jìn)行比較從而實(shí)現(xiàn)壓縮。幀間壓縮一般是無損的，其中幀差值算法是一種典型的時間壓縮方法。該算法通過對比本幀與相鄰幀之間的差異，僅記錄本幀與其相鄰幀的差值信息。這樣一來，就能夠大大減少數(shù)據(jù)量，因?yàn)樵诤芏嗲闆r下，相鄰幀之間的變化往往是局部的、微小的，只需要記錄這些變化部分，在播放時結(jié)合相鄰幀的信息即可還原出當(dāng)前幀的畫面，從而實(shí)現(xiàn)高效的視頻壓縮。

編碼壓縮的步驟大致如下：

1. 分組，也就是將一系列變換不大的圖像歸為一個組，也就是一個序列，也就是 GOP；
2. 定義幀，將每組的圖像幀歸分為 I 幀、P 幀和 B 幀三種類型；
3. 預(yù)測幀，以 I 幀做為基礎(chǔ)幀，以 I 幀預(yù)測 P 幀，再由 I 幀和 P 幀預(yù)測 B 幀；
4. 數(shù)據(jù)傳輸，最后將 I 幀數(shù)據(jù)與預(yù)測的差值信息進(jìn)行存儲和傳輸。

碼流結(jié)構(gòu)

• H.264碼流結(jié)構(gòu)
• 音視頻基礎(chǔ)：H265/HEVC&碼流結(jié)構(gòu)
• H.265 如何比 H.264 提升 40% 編碼效率

從碼流功能角度分為 NAL 層和 VCL 層。NAL 網(wǎng)絡(luò)抽象層負(fù)責(zé)以網(wǎng)絡(luò)所要求的恰當(dāng)?shù)姆绞綄?shù)據(jù)進(jìn)行打包和傳送。VCL 視頻編碼層包括核心壓縮引擎和塊，宏塊和片的語法級別定義，設(shè)計目標(biāo)是盡可能地獨(dú)立于網(wǎng)絡(luò)進(jìn)行高效的編碼。

從碼流功能角度可分為 NAL（網(wǎng)絡(luò)抽象層） 和 VCL（視頻編碼層） 。

NAL 負(fù)責(zé)以網(wǎng)絡(luò)所要求的恰當(dāng)方式對數(shù)據(jù)進(jìn)行打包和傳送。它能夠根據(jù)不同的網(wǎng)絡(luò)環(huán)境和傳輸需求，對視頻編碼數(shù)據(jù)進(jìn)行有效的封裝和處理，確保數(shù)據(jù)能夠在各種網(wǎng)絡(luò)條件下穩(wěn)定傳輸。

VCL 則包括核心壓縮引擎以及塊、宏塊和片的語法級別定義。其設(shè)計目標(biāo)是盡可能地獨(dú)立于網(wǎng)絡(luò)進(jìn)行高效的編碼。VCL 專注于視頻內(nèi)容的壓縮編碼，通過各種先進(jìn)的編碼技術(shù)去除視頻中的冗余信息，以實(shí)現(xiàn)高壓縮比和良好的圖像質(zhì)量。

碼流是由一個個 NALU（NAL Unit）組成的，每個 NAL 單元包括 NALU頭 + RBSP。

一幀圖片經(jīng)過 H.264 編碼器之后，會被編碼為一個或多個切片（Slice）。而 NALU（Network Abstraction Layer Unit，網(wǎng)絡(luò)抽象層單元）則是這些切片的載體。切片的存在主要是為了限制誤碼的擴(kuò)散和傳輸。切片頭中包含著諸多重要信息，如切片類型、切片中的宏塊類型、切片幀的數(shù)量、切片所屬的圖像以及對應(yīng)的幀的設(shè)置和參數(shù)等。切片體所包含的數(shù)據(jù)則是宏塊。宏塊作為視頻信息的主要承載者，除了含有宏塊類型、預(yù)測類型、編碼塊模式和量化參數(shù)之外，還包含著每一個像素的亮度分量（Y）以及色度信息（藍(lán)色色度分量 Cb、紅色色度分量 Cr）。視頻解碼的主要工作就在于提供高效的方式，從碼流中獲取宏塊中的像素陣列，從而實(shí)現(xiàn)視頻的播放和顯示。

H.265 引入了編碼樹單元（Coding Tree Unit，CTU）和編碼樹塊（Coding Tree Block，CTB）。在 H.265 中，CTU 的概念與 H.264 的宏塊有一定的相似性，但也存在明顯區(qū)別。H.264 的宏塊采用固定的 16×16 的離散余弦變換（DCT），而 H.265 的 CTU 則同時運(yùn)用了離散余弦變化（DCT）和離散正弦變化（DST），并且像素大小為 4×4 到 64×64 的動態(tài)可變塊，這種設(shè)計使得 H.265 在處理不同類型的圖像內(nèi)容時更加靈活高效。其中，每個 CTU 也是由一個亮度 CTB（Y）、兩個色度 CTB（Cb 和 Cr）以及一些關(guān)聯(lián)的語法元素組成。這些語法元素為解碼器提供了必要的信息，以便正確地解析和重建視頻圖像。通過這種方式，H.265 能夠在保證圖像質(zhì)量的前提下，進(jìn)一步提高壓縮效率，減少視頻文件的大小，適應(yīng)不同的網(wǎng)絡(luò)環(huán)境和存儲需求。

H.264/AVC Macroblocks

H.265/HEVC Macroblocks

• YCbCr - YUV 的衍生版本，用于數(shù)字視頻處理領(lǐng)域，將色彩空間分為亮度分量（Y）和色度分量（Cb、Cr），Y 代表亮度、Cb 代表藍(lán)色色度分量、Cr 代表紅色色度分量。
• MB - 宏塊（Macro Block），在不同的編碼標(biāo)準(zhǔn)有不同的叫法， H.264/AVC 的 MB 是視頻編碼的基本單元，常見的大小有 16x16、64x64 等。編碼時每一幀畫面都會被按照固定大小分割成大量 MB。
• CBP - 編碼塊模式（Coded Block Pattern），描述視頻幀的分塊方式，例如實(shí)際選擇 8×8 還是 16×16 的宏塊進(jìn)行編碼處理。其選擇和應(yīng)用取決于視頻內(nèi)容的特性、編碼效率的要求以及傳輸或存儲的限制。
• QP - 量化參數(shù)（Quantization Parameter）。視頻壓縮一般為有損壓縮，編碼時需要為每一幀以及每一個 MB 選擇 QP，用以控制畫面質(zhì)量與碼率。QP 越大，則損失的信息越多，畫面質(zhì)量越差，但壓縮率也越高。

優(yōu)化算法

音頻優(yōu)化

音頻去噪

根據(jù)噪聲與信號的相關(guān)性，可將噪聲分為加性噪聲和乘性噪聲。加噪信號是指噪聲與信號呈加和關(guān)系，此時信號和噪聲是不相關(guān)的。例如，在音頻錄制過程中，環(huán)境中的白噪聲與音頻信號疊加在一起，就屬于加性噪聲。乘性噪聲是指噪聲和信號為乘積關(guān)系，此時噪聲和信號是相關(guān)聯(lián)的。例如，在無線通信過程中，由于信道衰落等因素，信號在傳輸過程中會受到與信號強(qiáng)度相關(guān)的噪聲影響，就屬于乘性噪聲。

時域去噪算法，基于時間域的濾波過程，發(fā)生在時間軸上，常見的包括移動平均法、中位值法、標(biāo)準(zhǔn)差法等。移動平均濾波器主要通過計算信號的移動平均值來達(dá)到消除噪聲的目的。其算法的主要思想是對信號進(jìn)行滑動窗口處理，將窗口內(nèi)的數(shù)據(jù)進(jìn)行平均化操作，從而得到平滑后的信號。這種方式能夠有效地去除周期性噪聲和高頻噪聲，因?yàn)檫@些噪聲在短時間內(nèi)的波動較大，通過平均化處理可以降低其影響。同時，移動平均法還能保留信號的整體趨勢，不會使信號在去噪過程中失去其主要特征。

頻域去噪算法，基于頻譜分析的濾波過程，發(fā)生在頻率軸上，常見的包括傅里葉變化、離散余弦變換等。對于音頻信號而言，離散傅里葉變換（DFT）是信號分析的最基本方法，它能把信號從時間域變換到頻率域，進(jìn)而研究信號的頻譜結(jié)構(gòu)和變化規(guī)律。通常會對音頻資源進(jìn)行一次快速傅里葉變換（FFT），然后再用濾波器過濾噪聲，常用的包括低通濾波器、高通濾波器、帶通濾波器和帶阻濾波器等。低/高通濾波器分別削弱高/低頻信號而保留低/高頻信號；帶通/阻濾波器是將某個頻率范圍的信號通過/削弱而削弱/通過其他頻率范圍內(nèi)的信號。

小波去噪算法，對含噪聲信號進(jìn)行小波變換，將信號從時域轉(zhuǎn)換到小波域；對變換得到的小波系數(shù)進(jìn)行某種處理，根據(jù)設(shè)定的閾值，將小于閾值的小波系數(shù)視為噪聲并進(jìn)行相應(yīng)的處理，而保留大于閾值的小波系數(shù)，認(rèn)為它們主要代表信號的特征；對處理后的小波系數(shù)進(jìn)行小波逆變換，得到去噪后的信號。小波去噪問題的本質(zhì)是一個函數(shù)逼近問題，即如何在由小波母函數(shù)伸縮和平移版本所展成的函數(shù)空間中，根據(jù)提出的衡量準(zhǔn)則，尋找對原信號的最佳逼近（閾值）。通過這種方式，能夠盡可能地區(qū)分原信號和噪聲信號，從而實(shí)現(xiàn)有效的去噪。

維納濾波算法是一種以最小平方為最優(yōu)準(zhǔn)則的線性濾波算法，利用輸入信號與量測信號的統(tǒng)計特性，通過求解維納-霍夫方程獲得在最小均方誤差準(zhǔn)則下的最優(yōu)解。由于維納濾波器要求得到半無限時間區(qū)間內(nèi)的全部觀察數(shù)據(jù)的條件很難滿足，同時它也不能用于噪聲為非平穩(wěn)的隨機(jī)過程的情況，所以在實(shí)際問題中應(yīng)用不多。卡爾曼濾波算法是維納濾波算法的發(fā)展，它解決沒有期望響應(yīng)作為參考信號和通信環(huán)境為非平穩(wěn)時的狀態(tài)估計問題，因此卡爾曼濾波器在各種最優(yōu)濾波和最優(yōu)控制問題中得到極其廣泛的應(yīng)用。

自適應(yīng)去噪算法，根據(jù)噪聲的特征來自動調(diào)整濾波器的系數(shù)，主要算法有 SDA、LMS、RLS 等。自適應(yīng)濾波是近年以來發(fā)展起來的一種最佳濾波方法，原理是利用前一時刻獲得的濾波結(jié)果，自動調(diào)節(jié)現(xiàn)時刻的濾波器參數(shù)，以適應(yīng)信號和噪聲的未知特性，它是在維納濾波、卡爾曼濾波等線性濾波基礎(chǔ)上發(fā)展起來的一種最佳濾波方法。其濾波器分為線性自適應(yīng)濾波器和非線性自適應(yīng)濾波器。絕大多數(shù)自適應(yīng)濾波器皆為線性濾波器，而非線性自適應(yīng)濾波器包括 Voetlrra 濾波器和基于神經(jīng)網(wǎng)絡(luò)的自適應(yīng)濾波器。

• 噪聲 - 不期望接收到的信號。
• 濾波 - 降噪的常用的手段。
• SDA - Steepest Descent Algorithm，最速下降法。
• LMS - Least Mean Square，最小均方法。
• RLS - Recursive Least Square，遞推最小二乘法。

回聲消除

AEC 背景介紹

產(chǎn)生回聲的原因是聲音信號經(jīng)過一系列反射之后再次被錄進(jìn)麥克風(fēng)。通信系統(tǒng)的回聲主要分為兩類：電路回聲和聲學(xué)回聲。

造成電路回聲的根本原因是轉(zhuǎn)換混合器的二線 - 四線阻抗無法完全匹配。這種不匹配使得混合器接收線路的語音信號流失到發(fā)送線路，進(jìn)而產(chǎn)生回聲信號。由于電路回聲信號具有線性且穩(wěn)定的特點(diǎn)，所以相對比較容易將其消除。

在麥克風(fēng)與揚(yáng)聲器互相作用影響的雙工通信系統(tǒng)中極易產(chǎn)生聲學(xué)回聲。聲學(xué)回聲信號根據(jù)傳輸途徑的差別可以分別直接回聲信號（線性回聲） 和間接回聲信號（非線性回聲） 。近端揚(yáng)聲器將語音信號播放出來后，被近端麥克風(fēng)直接采集后得到的回聲為直接回聲。直接回聲不受環(huán)境的影響，主要與揚(yáng)聲器到麥克風(fēng)的距離及位置有很大的關(guān)系，因此直接回聲是一種線性信號。而近端揚(yáng)聲器將語音信號播放出來后，語音信號經(jīng)過復(fù)雜多變的墻面反射后由近端麥克風(fēng)采集，這種回聲為間接回聲。間接回聲的大小與房間環(huán)境、物品擺放以及墻面吸引系數(shù)等等因素有關(guān)，所以間接回聲是一種非線性信號。

針對回聲消除（AEC，Acoustic Echo Cancellation）問題，目前最流行的算法是基于自適應(yīng)濾波的回聲消除算法。該算法通過使用自適應(yīng)濾波算法來調(diào)整濾波器的權(quán)值向量，其目的是計算出近似的回聲路徑，以無限逼近真實(shí)回聲路徑。這樣一來，就能夠得到估計的回聲信號。然后，在語音和回聲的混合信號中除去此估計的回聲信號，從而實(shí)現(xiàn)回聲的消除。

音量均衡

• What is Loudness?
• Convert loudness between phon and sone units
• 如何理解“音量”和“響度”的概念？
• 主流網(wǎng)絡(luò)平臺音量歸一化方案調(diào)研

由于不同視頻的錄制音量不同，在極端情況下(尖叫聲、爆炸聲)會嚴(yán)重影響用戶觀看體驗(yàn)。音量低，則會聽不清，需要調(diào)大音量；音量高，則太吵了，需要降低音量；音量均衡，通過調(diào)整音頻信號的音量，使得不同頻率的聲音在聽覺上的強(qiáng)度大致相等，從而獲得更加均衡和自然的音質(zhì)。

音量均衡 前的波形圖

音量均衡 后的波形圖

衡量聲音的大小往往會用到“音量 Volume”和“響度 Loudness”，分貝（dB/dBSPL）不能像赫茲、克、米那樣給出一個客觀的量，而只能給出兩個相同物理量的比值，所以是一種相對的概念。人耳對不同頻率的“響度”感受存在差異，如下圖的“等響曲線”圖。其中 phon 是響度級的單位，規(guī)定在 1000Hz 時，1dBSPL=1phon。在 40phon 以上的區(qū)域，當(dāng)聲壓提高十倍時，人類的聽覺感知只會提高兩倍。為了讓響度和聽覺感知盡量呈線性關(guān)系，需要引入另一個響度單位 sone，40phon 等同于 1sone。

等響曲線圖

過去，工程師們常常結(jié)合使用峰值表、VU 表以及他們的耳朵來確定音軌的真實(shí)感知響度，然而，這種方式存在一定的局限性。2000 年，Katz 提出了一種 K-Metering 的計量標(biāo)準(zhǔn)，該標(biāo)準(zhǔn)將過去的最佳概念與當(dāng)前的心理聲學(xué)相結(jié)合。雖然不同類型的音樂需要不同的動態(tài)余量，但這種方式能夠?qū)⒁魳返钠骄綐?biāo)準(zhǔn)化。在此基礎(chǔ)上，將 K-Metering 進(jìn)一步完善后，現(xiàn)代標(biāo)準(zhǔn)計量方法 LKFS 被國際電信聯(lián)盟（ITU）制定并發(fā)布，從而實(shí)現(xiàn)了視頻格式音頻電平的標(biāo)準(zhǔn)化。如今，大多數(shù)廣播、電影和視頻游戲公司都采用 LKFS 作為測量響度的標(biāo)準(zhǔn)。LKFS 的采用使得音頻制作和播放更加規(guī)范和統(tǒng)一，有助于提高音頻質(zhì)量和用戶體驗(yàn)。同時，它也為不同平臺和設(shè)備之間的音頻兼容性提供了保障。

• LKFS/LUFS - Loudness K-weighted Full Scale，國際電信聯(lián)盟制定的響度測量單位，即相對于滿量程的 K 加權(quán)響度。LUFS 是歐洲廣播聯(lián)盟在 LKFS 基礎(chǔ)上制定的（沒談攏），目前而言兩者可以等價。

空間音頻

• 空間音頻小百科
• 空間音頻科普篇
• 聲網(wǎng) MetaKTV 技術(shù)揭秘之“聲臨其境”：3D 空間音效+空氣衰減+人聲模糊

空間音頻（Spatial Audio）與環(huán)繞聲（Surround Sound）不同，它能夠模擬固定空間位置的音響設(shè)備。當(dāng)用戶轉(zhuǎn)動頭部或者移動設(shè)備時，都能感受到身臨其境的環(huán)繞聲體驗(yàn)，而不僅僅是傳統(tǒng)的環(huán)繞聲效果。其實(shí)現(xiàn)原理在于，人對聲音方位感的判斷主要有四個依據(jù)：時間差、聲級差、人體濾波效應(yīng)、頭部晃動。

雙耳位于頭顱兩側(cè)，當(dāng)發(fā)聲源不在雙耳連線段的中垂面上時，聲音到達(dá)雙耳的傳輸距離就會不同。由于距離的差異，聲音到達(dá)雙耳的時間便會產(chǎn)生差異，這個差異被稱為時間差 ITD（Interaural Time Difference）。ITD 是人類判斷聲音方位的重要依據(jù)之一。大腦可以根據(jù)這種時間差來確定聲音來自哪個方向。例如，當(dāng)聲音從左側(cè)傳來時，聲音到達(dá)左耳的時間會比到達(dá)右耳的時間早一些。

時間差的存在以及聲功率隨傳播距離衰減的特性，雙耳和音源的距離差異以及頭部的遮擋，會使得到達(dá)左耳與右耳聲音的聲壓級不同，進(jìn)而形成聲級差 ILD（Interaural Level Difference）。ILD 同樣是人類判斷聲音方位的重要依據(jù)之一。當(dāng)聲音從不同方向傳來時，由于距離和遮擋等因素，左右耳接收到的聲音強(qiáng)度會有所不同。大腦通過對這種聲級差的感知和分析，可以進(jìn)一步確定聲音的來源方向。例如，當(dāng)聲音從右側(cè)傳來時，右耳接收到的聲音強(qiáng)度通常會比左耳大一些。

人體濾波效應(yīng)是指頭部、肩頸、軀干會對不同方向的聲音產(chǎn)生不同的作用，形成反射、遮擋或衍射。尤其是外耳，通過耳廓上不同的褶皺結(jié)構(gòu)，對不同方向的聲音產(chǎn)生不同的濾波效果，大腦通過這些濾波效果產(chǎn)生對聲源方位的判斷。當(dāng)聲音從不同方向傳入耳朵時，耳廓會對聲音進(jìn)行特定的改變。不同方向的聲音經(jīng)過耳廓的反射、衍射等作用后，其頻率特性會發(fā)生變化。大腦通過識別這些濾波效果，能夠產(chǎn)生對聲源方位的判斷。例如，聲音從前方傳來時，耳廓對聲音的改變相對較小；而當(dāng)聲音從后方傳來時，耳廓會對聲音進(jìn)行較大程度的改變。

時間差、聲級差、人體濾波效應(yīng)這三個要素合稱為頭部相關(guān)傳輸函數(shù)（Head-Related Transfer Functions, HRTFs）。而頭部的晃動會改變時間差、聲級差或人體濾波效應(yīng)。Y軸 - 左右定位 = 時間差 + 聲級差 + 頭部晃動；X軸 - 前后定位 = 人體濾波效應(yīng) + 頭部晃動；Z軸 - 上下定位 = 人體濾波效應(yīng) + 頭部晃動。頭部的晃動與時間差、聲級差、人體濾波效應(yīng)相互配合，共同幫助人類在三維空間中準(zhǔn)確地定位聲音的來源。

杜比全景聲（Dolby Atmos）作為杜比實(shí)驗(yàn)室研發(fā)的 3D 環(huán)繞聲技術(shù)，是目前空間音頻最為成功的應(yīng)用之一。杜比全景聲突破了傳統(tǒng)意義上 5.1 聲道、7.1 聲道的概念，不再局限于固定的聲道布局。它能夠緊密結(jié)合影片內(nèi)容，呈現(xiàn)出極具動態(tài)的聲音效果。在觀影過程中，聲音可以隨著畫面中的情節(jié)發(fā)展而變化，從輕柔的低語到震撼的巨響，都能精準(zhǔn)地傳達(dá)，讓觀眾仿佛置身于影片的世界之中。更真實(shí)地營造出由遠(yuǎn)及近的音效是杜比全景聲的一大特色。通過對聲音的精細(xì)處理，觀眾可以清晰地感受到聲音從遠(yuǎn)處逐漸靠近，或者從近處漸漸遠(yuǎn)去，極大地增強(qiáng)了沉浸感。配合頂棚加設(shè)音箱，杜比全景聲實(shí)現(xiàn)了聲場包圍。聲音不再僅僅從前方和兩側(cè)傳來，而是從各個方向包括上方包圍觀眾，展現(xiàn)出更多的聲音細(xì)節(jié)。無論是雨滴落下的細(xì)微聲響，還是飛機(jī)從頭頂飛過的轟鳴聲，都能被清晰地捕捉到，從而極大地提升了觀眾的觀影感受。

視頻優(yōu)化

碼控算法

• 常用碼率控制算法分析
• 視頻碼率控制原理
• H.264 碼率控制原理
• H.264 的碼率控制算法

碼率控制在編碼器中占據(jù)著至關(guān)重要的地位，其主要作用是通過特定的算法來有效控制編碼器輸出碼流的大小。碼率控制主要包括兩部分：碼率分配、量化參數(shù)（QP）調(diào)整。

H.264/AVC 的碼率控制算法采用多種技術(shù)，包括自適應(yīng)基本單元層（Adaptive Basic Unit Layer）、流量往返模型（Fluid Traffic Model）、線性 MAD 模型、二次率失真模型（RD）等。H.264/AVC 采用分層碼率控制策略，包括 GOP 層、幀層和基本單元層。

碼率控制器負(fù)責(zé)收集碼率、延時和緩沖區(qū)狀態(tài)信息并調(diào)節(jié)編碼參數(shù)，使得性能指標(biāo)維持在給定水平上。緩沖區(qū)起平滑碼率波動的作用。在編碼端，數(shù)據(jù)輸入緩沖區(qū)的碼率是變化的，而輸出碼率則取決于碼率控制的模式。

幀層碼率控制根據(jù)網(wǎng)絡(luò)帶寬、緩存占用量、緩存大小及剩余比特來分配每一幀的目標(biāo)比特；基本單元層碼率控制目標(biāo)比特由該幀的剩余目標(biāo)比特平均得到。

常見的碼率控制算法包括固定碼率（Constant Bit Rate）、可變碼率（Variable Bit Rate）、平均碼率（Average Bit Rate）等。

不同類型的視頻資源對于畫面質(zhì)量和碼率穩(wěn)定性的權(quán)重不同。

離線視頻，往往不需要穩(wěn)定的碼率，而對畫面質(zhì)量有較高要求，通常采用可變碼率。畫面紋理比較復(fù)雜或運(yùn)動劇烈的場景，碼率給高一些，以保證畫面質(zhì)量；而畫面簡單的場景，碼率就給低一些，節(jié)省硬盤空間。

在線視頻則對碼率穩(wěn)定性有較高要求，對畫面質(zhì)量要求相對低一些，通常采用恒定碼率。由于用戶帶寬有限，客戶端緩存的數(shù)據(jù)量也有限，一些瞬時碼率過高的片段可能會引起卡頓。CDN 是按流量計費(fèi)的，視頻網(wǎng)站如果使用可變碼率編碼視頻會使帶寬成本變得不可控。

帶寬預(yù)測是實(shí)現(xiàn)碼率自適應(yīng)的基礎(chǔ)，原理是根據(jù)網(wǎng)絡(luò)實(shí)時狀況或客戶端延時自動調(diào)整流媒體碼率。帶寬預(yù)測通過控制音視頻發(fā)送的數(shù)據(jù)量，避免在網(wǎng)絡(luò)帶寬不足時發(fā)送超出網(wǎng)絡(luò)帶寬的數(shù)據(jù)，導(dǎo)致長延時和高丟包等問題。包括基于延時的帶寬預(yù)測算法、基于丟包的帶寬預(yù)測算法以及最大帶寬探測算法等。而碼率自適應(yīng)包括兩種主流算法：基于速率的碼率自適應(yīng)算法 Rate-based ABR Algorithms：衡量網(wǎng)絡(luò)連接速度、根據(jù)速度改變視頻加載質(zhì)量；基于緩沖的碼率自適應(yīng)算法 Buffer-based ABR Algorithms：提前加載視頻未播放的部分。

Jitter Buffer

• Jitter Buffer
• WebRTC-QOS之JitterBuffer詳解

Jitter Buffer 是一個共享數(shù)據(jù)區(qū)域，又稱為抖動緩沖區(qū)，主要作用是處理數(shù)據(jù)包丟失、亂序、延遲到達(dá)等情況，進(jìn)而平滑地向解碼模塊輸出數(shù)據(jù)包/幀，抵抗各種弱網(wǎng)情況對播放造成的影響，降低卡頓并提高用戶的觀看體驗(yàn)（花屏、卡頓等）。

網(wǎng)絡(luò)抖動是指網(wǎng)絡(luò)傳輸數(shù)據(jù)時，在數(shù)據(jù)包到達(dá)接收方之前，網(wǎng)絡(luò)傳輸所引起的延遲波動或數(shù)據(jù)包丟失現(xiàn)象，產(chǎn)生原因包括：

1. 傳輸路徑，上一時刻的路由發(fā)生故障，數(shù)據(jù)包路徑變更導(dǎo)致端到端的傳輸時長發(fā)生改變；
2. 網(wǎng)絡(luò)擁塞，分組交換網(wǎng)絡(luò)中傳送分組的數(shù)目太多時，由于存儲轉(zhuǎn)發(fā)節(jié)點(diǎn)的資源有限而造成網(wǎng)絡(luò)傳輸性能下降的情況，常伴隨數(shù)據(jù)丟失、時延增加、吞吐量下降，嚴(yán)重時甚至?xí)?dǎo)致“擁塞崩潰”。
3. 擁塞控制，慢啟動、擁塞避免、快重傳、快恢復(fù)等手段帶來的額外抖動。

JitterBuffer 本質(zhì)上是用時間換穩(wěn)定性，以增大端到端的延遲為代價來換取視頻通話的流暢性。主要工作流程包括接收數(shù)據(jù)包、排序數(shù)據(jù)包、緩沖數(shù)據(jù)包，WebRTC 上述過程稱為組幀處理邏輯，分為包的排序（PacketBuffer）、幀的排序（RtpFrameReferenceFinder）以及 GOP 的排序（FrameBuffer）。當(dāng)網(wǎng)絡(luò)抖動時，增加 Buffer 的容量，多緩存一些數(shù)據(jù)作為緩沖池；當(dāng)網(wǎng)絡(luò)穩(wěn)定時，減小 Buffer 的容量，降低資源傳輸端到端的延遲。

可伸縮編碼

H.264可伸縮編碼 SVC

可伸縮視頻編碼（Scalable Video Coding，SVC）對視頻信號編碼分層，當(dāng)帶寬不足時只對基本層的碼流進(jìn)行傳輸和解碼，但這時解碼的視頻質(zhì)量不高。當(dāng)帶寬充足時，傳輸和解碼增強(qiáng)層的碼流來提高視頻的解碼質(zhì)量。

所謂分層就是在時間、空間、質(zhì)量（信噪比）上進(jìn)行劃分，輸出多層碼流（包括基本層和增強(qiáng)層）。

時間可伸縮性是指將視頻流分解成表示不同幀率的信息；空間可伸縮性是指將視頻流分解成表示不同分辨率的信息；質(zhì)量可伸縮性是指將像素值分解成不同級別。根據(jù)可伸縮編碼的壓縮編碼架構(gòu)的不同，可以分為基于 DCT 變換的視頻編碼和基于小波變換的可伸縮視頻編碼。

基本層的數(shù)據(jù)可以使解碼器完全正常的解碼出基本視頻內(nèi)容，但是基本層的數(shù)據(jù)獲得的視頻圖像幀率較低，分辨率較低，或者質(zhì)量較低。在信道受限或信道環(huán)境復(fù)雜時，可以保證解碼端能夠接收到可以觀看的流暢視頻圖像。當(dāng)信道環(huán)境良好或信道資源豐富時，可以傳遞增強(qiáng)層數(shù)據(jù)，以提高幀率，或分辨率，或視頻質(zhì)量。而增強(qiáng)層是可以多層編碼的，這就意味著，在視頻碼流總碼率的范圍內(nèi)，接收到的碼率越大，視頻質(zhì)量越好。

行業(yè)標(biāo)準(zhǔn)

視頻流從加載到準(zhǔn)備播放是需要經(jīng)過解協(xié)議、解封裝、解編碼等這樣的過程，協(xié)議指的就是流媒體協(xié)議；封裝是的是媒體封裝格式；編碼又分為視頻編碼和音頻編碼。

編碼協(xié)議

• 網(wǎng)頁音頻編碼指南
• 網(wǎng)頁視頻編碼指南
• 國內(nèi)外視頻編解碼標(biāo)準(zhǔn)體系
• 音視頻基礎(chǔ)-視頻編碼

常見的 mp4、flv、mov、avi 等稱為封裝 協(xié)議，而 H264、H265、VP8、VP9 等則被稱為編碼協(xié)議。封裝格式內(nèi)部包含視頻軌（視頻編碼文件）、音頻軌（音頻編碼文件）、字幕軌以及視頻寬高等編解碼信息。

不同組織主導(dǎo)制定的視頻編碼協(xié)議，常見的包括 3 大類：

• ISO-MPEG / ITU-T 系列，由國際標(biāo)準(zhǔn)組織機(jī)構(gòu)（ISO）下屬的運(yùn)動圖象專家組（MPEG）和國際電傳視訊聯(lián)盟遠(yuǎn)程通信標(biāo)準(zhǔn)化組織（ITU-T）開發(fā)的系列編碼標(biāo)準(zhǔn)。
• AOM 系列，前身是由 Google 內(nèi)部使用的 VPx 系列的編碼標(biāo)準(zhǔn)。后續(xù) Microsoft、Netflix 等多家科技巨頭加入組建成立開放媒體聯(lián)盟（Alliance for Open Media，AOM）。
• AVS 系列，數(shù)字音視頻編解碼技術(shù)標(biāo)準(zhǔn)（Audio Video coding Standard）是國內(nèi)具備自主知識產(chǎn)權(quán)的信源編碼標(biāo)準(zhǔn)體系。

ISO-MPEG / ITU-T 系列

Publicly Available Standards

MPEG 是運(yùn)動圖像專家組制定的一種運(yùn)動圖像壓縮算法國際標(biāo)準(zhǔn)，采用有損壓縮方法減少運(yùn)動圖像中的冗余信息，即根據(jù)大部分相鄰畫面的相似性特點(diǎn)，把后續(xù)圖像和前面圖像共有的冗余部分去除，從而達(dá)到壓縮的目的。為了達(dá)到更好的壓縮率，MPEG 引入了除 I幀、P幀之外的第三種幀—— B幀。

MPEG-1，頒布于 1993 年，針對 1.5Mbps 以下數(shù)據(jù)傳輸率的數(shù)字存儲媒體運(yùn)動圖像及其伴音編碼而設(shè)計的國際標(biāo)準(zhǔn)。為 CD 光盤介質(zhì)定制的視頻和音頻壓縮格式，是 VCD 的制作格式。使用 MPEG-1 壓縮算法，可以把一部 120 分鐘長的電影壓縮到 1.2GB 左右大小。最為知名的是音頻第三代壓縮協(xié)議，被稱為 MPEG-1 Layer 3，簡稱 MP3。

MPEG-2，頒布于 1995 年，設(shè)計目標(biāo)是高級工業(yè)標(biāo)準(zhǔn)的圖像質(zhì)量以及更高的傳輸率。這種格式主要應(yīng)用在DVD/SVCD 的制作格式，同時在一些 HDTV（高清晰電視廣播）和一些高要求視頻編輯、處理上面也有廣泛應(yīng)用。使用 MPEG-2 壓縮算法，可以把一部 120分鐘長的電影壓縮到 4~8GB 的大小。

MPEG-4，頒布于 1999 年，是為了播放流式媒體的高質(zhì)量視頻而專門設(shè)計的，它可利用很窄的帶度，通過幀重建技術(shù)壓縮和傳輸數(shù)據(jù)，以求使用最少的數(shù)據(jù)獲得最佳的圖像質(zhì)量。這種文件格式包含以前 MPEG 壓縮標(biāo)準(zhǔn)所不具備的比特率的可伸縮性、動畫精靈、交互性、版權(quán)保護(hù)等功能。MPEG-4 由一系列子標(biāo)準(zhǔn)組成，著名的 MP4 是該標(biāo)準(zhǔn)的第十四卷（ISO/IEC 14496-14）。

ITU-T 在 1990 年最先研究出 H.261，這是第一個實(shí)用化國際標(biāo)準(zhǔn)，后來在 1995 年和 1996 年先后發(fā)布 H.262、H.263，指導(dǎo)后來的H視頻編解碼器，這是ITU-T的H26x系列。

MPEG 和 ITU-T 兩個組織在 2000 年組成聯(lián)合視頻工作組 JVT，在原 H.264 的基礎(chǔ)上共同研發(fā)，頒布更為成熟的 H.264/AVC 協(xié)議。ITU-T 更愿意稱之為 H.264，而 MPEG 組織則稱之為 MPEG-AVC。H.264/AVC 的壓縮方法大致包括：分組，把幾幀圖像分為一組（GOP），防止運(yùn)動變化；定義幀，每組內(nèi)各幀圖像定義為三種類型，即 I幀、B幀 和 P幀；預(yù)測幀，以 I幀做為基礎(chǔ)幀，預(yù)測 P幀，再由 I幀和 P幀預(yù)測 B幀；數(shù)據(jù)傳輸，最后將 I幀數(shù)據(jù)與預(yù)測的差值信息進(jìn)行傳輸。

2013 年 H.265/HEVC 被批準(zhǔn)為國際標(biāo)準(zhǔn)，與 H.264/AVC 相比，它采用分層四叉樹的優(yōu)化宏塊分割算法。前者是16×16 固定像素的宏塊，后者是 4×4 到 64×64 動態(tài)像素的宏塊。因此能更好的支持包括 8K UHD（7680 × 4320）的高分辨率資源的存儲與傳輸。

2018 年 MPEG 和 VCEG 成立的聯(lián)合視頻探索小組（JVET）開始將 H.266/VVC 標(biāo)準(zhǔn)化。新標(biāo)準(zhǔn)要求在相同的體驗(yàn)質(zhì)量的前提下，同 H.265/HEVC 相比，壓縮率優(yōu)化 30% 到 50%，并支持無損壓縮；最大宏塊從 64х64 增加到 128х128，支持 4K 到 16K 分辨率以及 VR 360°；支持具有 4:4:4、4:2:2 和 4:2:0 量化的 YCbCr 色彩空間；每個組件顏色深度為 8 位到 16 位；BT.2100 和 16+ 步高動態(tài)范圍 (HDR)；輔助通道，如深度通道、阿爾法通道等；從 0 到 120 Hz 的可變幀率；具有時間（幀速率變化）和空間（分辨率變化）可伸縮性的可伸縮編碼；SNR、立體/多視圖編碼、全景格式和靜止圖像編碼。

AOM 系列

• Get Started with AV1, AVIF & IAMF
• 主流顯卡VP9、AV1硬件解碼支持列表

由于 H.26X 相關(guān)標(biāo)準(zhǔn)都是收費(fèi)的，崇尚開源的 Google 聯(lián)合 Amazon、Cisco、Intel、Microsoft、Mozilla 以及 Netflix 等互聯(lián)網(wǎng)巨頭成立開放媒體聯(lián)盟（Alliance for Open Media），旨在通過制定全新、開放、免版權(quán)費(fèi)的視頻編碼標(biāo)準(zhǔn)和視頻格式。

VP8 是一個開放的圖像壓縮格式，最早由 On2 Technologiesis 開發(fā)，后被 Google 收購并發(fā)布 VP8 編碼的實(shí)做庫：libvpx，早期以 BSD 授權(quán)條款的方式發(fā)布，隨后也附加專利使用權(quán)，但最終還是被確認(rèn)為開放源代碼授權(quán)。VP9 則是 Google 提供的開源免費(fèi)視頻編碼格式，對標(biāo) H.265/HEVC，除 IE9 以下版本的瀏覽器外，現(xiàn)代瀏覽器都支持 VP9 視頻編碼。

AV1 是由 AOM（Alliance for Open Media，開放媒體聯(lián)盟）于 2018 年制定的一個開源、免版權(quán)費(fèi)的視頻編碼格式，是 Google VP10、Mozilla Daala 以及 Cisco Thor 三款開源編碼項(xiàng)目共同研發(fā)的成果，目標(biāo)是解決 H.265 昂貴的專利費(fèi)用和復(fù)雜的專利授權(quán)問題并成為新一代領(lǐng)先的免版權(quán)費(fèi)的編碼標(biāo)準(zhǔn)（保持實(shí)際解碼復(fù)雜性和硬件可行性的同時，在最先進(jìn)的編解碼器上實(shí)現(xiàn)顯著的壓縮增益）。此外，AV1 是 VP9 標(biāo)準(zhǔn)的繼任者，也是 H.265 強(qiáng)有力的競爭者。AV1 第一次引入仿射變換運(yùn)動模型，打破傳統(tǒng)的二維運(yùn)動矢量模型的限制，不僅可以描述平移運(yùn)動，同時能夠表述如旋轉(zhuǎn)、縮放等更加復(fù)雜的運(yùn)動，有效的提升視頻編碼效率。AV1 比 H265/HEVC 壓縮率提升約 27%。目前，硬件設(shè)備的兼容性問題是阻礙其大范圍推廣的主要因素之一。

AVS 系列

• 數(shù)字音視頻編解碼技術(shù)標(biāo)準(zhǔn)工作組
• 一文讀懂AVS的發(fā)展歷程、關(guān)鍵技術(shù)及應(yīng)用展望

AVS 是基于我國創(chuàng)新技術(shù)和部分公開技術(shù)的自主標(biāo)準(zhǔn)，主要應(yīng)用于超高清電視節(jié)目的傳輸。AVS1 編碼（2006年）效率比原視頻編碼國家標(biāo)準(zhǔn)（等同于 MPEG-2）高 2-3 倍，與 H.264/AVC 相當(dāng)，達(dá)到第二代信源標(biāo)準(zhǔn)的最高水平；AVS1 通過簡潔的一站式許可政策，解決 H.264/AVC 專利許可問題死結(jié)，是開放式制訂的國家、國際標(biāo)準(zhǔn)，易于推廣；AVS2 編碼（2016年）效率比第一代標(biāo)準(zhǔn)提高一倍以上，壓縮效率超越國際標(biāo)準(zhǔn) H.265/HEVC。AVS3 編碼（2021年）采用更具復(fù)雜視頻內(nèi)容適應(yīng)性的擴(kuò)展四叉樹劃分，主要面向 8K 超高清，2022 年 1 月 1 日北京電視臺冬奧紀(jì)實(shí)頻道就是采用 AVS3 視頻標(biāo)準(zhǔn)播出的。

AVS 是一套包含系統(tǒng)、視頻、音頻、數(shù)字版權(quán)管理在內(nèi)的完整標(biāo)準(zhǔn)體系。我國牽頭制定的、技術(shù)先進(jìn)的第二代信源編碼標(biāo)準(zhǔn)；領(lǐng)導(dǎo)國際潮流的專利池管理方案，完備的標(biāo)準(zhǔn)工作組法律文件；制定過程開放、國際化。

AVS 產(chǎn)品形態(tài)包括：1）芯片：高清晰度/標(biāo)準(zhǔn)清晰度 AVS 解碼芯片和編碼芯片，國內(nèi)需求量在未來十多年的時間內(nèi)年均將達(dá)到 4000 多萬片；2）軟件：AVS 節(jié)目制作與管理系統(tǒng)，Linux 和 Window 平臺上基于 AVS 標(biāo)準(zhǔn)的流媒體播出、點(diǎn)播、回放軟件；3）整機(jī)：AVS 機(jī)頂盒、AVS 硬盤播出服務(wù)器、AVS 編碼器、AVS 高清晰度激光視盤機(jī)、AVS 高清晰度數(shù)字電視機(jī)頂盒和接收機(jī)、AVS 手機(jī)、AVS 便攜式數(shù)碼產(chǎn)品等。

• MPEG - Moving Picture Expert Group，隸屬于國際標(biāo)準(zhǔn)化組織 ISO/IEC，是專門負(fù)責(zé)視頻編解碼標(biāo)準(zhǔn)化方面的工作組。
• ITU-T - ITU Telecommunication Standardization Sector，隸屬于國際電信聯(lián)盟 ITU，是專門制定電信標(biāo)準(zhǔn)的分支機(jī)構(gòu)。
• JVT - Joint Video Team，成員主要來自 ISO/IEC 的 MPEG 專家組以及來自 ITU-T 的 VCEG 專家組。
• VCD - Video Compact Disc，分辨率約 352 × 240，并使用固定的比特率（1.15Mbps），因此在播放快速動作的視頻時，由于數(shù)據(jù)量不足，令壓縮時宏區(qū)塊無法全面調(diào)整，使視頻畫面出現(xiàn)模糊的方塊。
• DVD - Digital Versatile Disc，分辨率約 720 × 480，比特率達(dá)到 1~10Mbps，音效質(zhì)量達(dá)到了24bit/96kHz的標(biāo)準(zhǔn)，并支持外掛的字幕和聲道，以及多角度欣賞等數(shù)碼控制功能。
• AVC - Advanced Video Coding，高級視頻編碼，亦稱為 H.264。
• AAC - Advanced Audio Coding，高級音頻編碼，是比 MP3 更先進(jìn)的音頻壓縮技術(shù)。
• HEVC - High Efficiency Video Coding，高效率視頻編碼，亦稱為 H.265。
• AV1 - Alliance for Open Media Video 1，AOMedia 推出的編解碼格式，目標(biāo)是取締前代 VP9。

點(diǎn)播協(xié)議

MP4 格式詳解

MP4 是最常見的數(shù)字多媒體容器格式，幾乎可以用來描述所有的媒體結(jié)構(gòu)，常用到 H.264/H.265 視頻編解碼器和 AAC 音頻編解碼器。MP4 文件是由一個個 Box 組成的，可以將其理解為一個數(shù)據(jù)塊，由 Header+Data 組成，Data 存儲媒體元數(shù)據(jù)和實(shí)際的音視頻碼流數(shù)據(jù)。Box 可以直接存儲數(shù)據(jù)塊，也可包含其它 Box，把包含其它 Box 的Box 稱為 Container Box。每個 MP4 文件有多個 Track，每個 Track 由多個 Chunk 組成，每個 Chunk 包含一組連續(xù)的 Sample。Track 對于媒體數(shù)據(jù)而言就是一個視頻序列或者音頻序列，除 Video Track 和 Audio Track 外，還有非媒體數(shù)據(jù)，比如 Hint Track，這種類型的 Track 包含媒體數(shù)據(jù)的指示信息或者字幕信息。Sample 即采樣，對應(yīng)視頻的一幀數(shù)據(jù)，音頻的一段固定時長數(shù)據(jù)。Sample 是媒體流的基本單元，Chunk 是數(shù)據(jù)存儲的基本單位。不管是 Track，還是 Chunk 和 Sample，都是以 Box 的形式存在。

RMVB（RealMedia Variable Bitrate）是一種可變比特率的多媒體數(shù)字容器格式，從 RM 格式的擴(kuò)展版。影片的靜止畫面和運(yùn)動畫面對壓縮采樣率的要求是不同的，如果始終保持固定的比特率，會對影片質(zhì)量造成浪費(fèi)。在 RMVB 格式使用興盛時期幾乎每一位電腦使用者電腦中的視頻文件，超過80%都會是RMVB格式。但如今已經(jīng)逐漸被 MP4 所取代。

MOV 是 Apple 公司的 QuickTime 指定多媒體容器格式，屬于流式視頻封裝格式，能被眾多的多媒體編輯及視頻處理軟件所支持。MOV 格式支持多軌道音頻，可以容納多個音頻流，如不同語言的音軌或不同的音頻效果；還支持字幕、章節(jié)標(biāo)記、元數(shù)據(jù)等功能，豐富視頻的交互性和信息展示。MOV 能夠提供高質(zhì)量的視頻壓縮，同時保持較小的文件大小，方便傳輸和存儲，被廣泛用于電影、電視劇等影視制作領(lǐng)域。

AVI（Audio Video Interleaved）音頻視頻交錯格式，由 Microsoft 推出的一種多媒體文件格式，是 MOV 格式的競品。AVI 曾經(jīng)是一種非常流行的格式，幾乎所有的播放器都支持這種格式。但 AVI 缺乏對有損編解碼器的原生支持導(dǎo)致不兼容性，微軟已經(jīng)放棄了 AVI 容器，轉(zhuǎn)而使用更新的、功能更豐富的 WMV 容器。WAV 則是 Microsoft 推出的一款標(biāo)準(zhǔn)數(shù)字音頻文件，優(yōu)點(diǎn)不失真，缺點(diǎn)體積大。

MKV（Matroska Multimedia Container），是一種能夠在單個文件里容納無限數(shù)量的視頻、音頻、圖片或字幕軌道的多媒體封裝格式，能容納多種不同類型編碼的視頻、音頻及字幕流，其開發(fā)目的是為了取代 AVI 格式。MKV 支持任何視頻編解碼器和任何音頻編解碼器。此外，MKV 是一種開放文件格式，不需要軟件或硬件播放器支付許可費(fèi)用即可支持它。

OGV 文件格式是以 Ogg 容器格式保存的視頻文件，它包含可能使用一種或多種不同編解碼器的視頻流，例如Theora，Dirac 或 Daala?？梢允褂酶鞣N媒體播放器來播放 OGV 文件。OGV 文件通常用于使用HTML5 <video>標(biāo)簽播放網(wǎng)頁視頻內(nèi)容。但是，即使文件包含視頻內(nèi)容，它們也通常在HTML源代碼中使用 ".ogg" 擴(kuò)展名進(jìn)行引用。

QLV 是騰訊視頻文件格式，需要用騰訊視頻打開。LV 是騰訊視頻的一種加密緩存文件格式，只有騰訊視頻播放器才能播放。要想使用其它播放器來播放 QLV 格式視頻，必須先將該視頻轉(zhuǎn)換為其它格式。

WebM 是一種開放、免費(fèi)的多媒體容器格式，用于存儲視頻、音頻和字幕等數(shù)據(jù)。WebM 格式由 Google 公司開發(fā)，使用 VP8 視頻編解碼器和 Vorbis 音頻編解碼器，可以在大多數(shù)現(xiàn)代網(wǎng)絡(luò)瀏覽器上進(jìn)行播放，旨在為網(wǎng)絡(luò)上的 HTML5 視頻提供一個高效的開放標(biāo)準(zhǔn)。

直播協(xié)議

• WebRTC 入門教程
• 實(shí)時傳輸 Web 音頻與視頻

直播大致可以分為會議直播和娛樂直播兩類場景。會議直播是需要實(shí)時互動的，主要考慮傳輸?shù)膶?shí)時性，一般采用 UDP 作為底層傳輸協(xié)議；娛樂直播則對實(shí)時性要求不高，更加關(guān)注畫面的質(zhì)量、音視頻卡頓等體驗(yàn)問題，一般采用 TCP 作為底層傳輸協(xié)議。

會議直播亦稱為實(shí)時互動直播，以 WebRTC 協(xié)議為主；娛樂直播亦稱為傳統(tǒng)直播，以 RTMP 和 HLS 協(xié)議為主。

WebSocket 是一種全雙工通訊的網(wǎng)絡(luò)技術(shù)，使得瀏覽器具備實(shí)時雙向通信的能力，建立在 TCP 長連接基礎(chǔ)上，可以復(fù)用 HTTP 的握手協(xié)議，通過減少每次連接的握手次數(shù)和數(shù)據(jù)包的開銷，提高通信的整體效率和性能。因此，WebSocket 協(xié)議在即時通信、游戲、在線聊天等場景中得到了廣泛應(yīng)用，它為 Web 應(yīng)用提供了更加高效、可靠的雙向通信方式。

WebRTC 是 RTC 在 Web 的一種實(shí)現(xiàn)形式，適用于各種實(shí)時通信場景，包括：點(diǎn)對點(diǎn)通訊，支持瀏覽器之間進(jìn)行音視頻通話，例如語音通話、視頻通話等；電話會議，支持多人音視頻會議，例如騰訊會議、釘釘會議等；屏幕共享，支持實(shí)時共享屏幕；直播，用于構(gòu)建實(shí)時直播，用戶可以通過瀏覽器觀看直播內(nèi)容。IM 即時通信，常用于文字聊天、語音消息發(fā)送、文件傳輸?shù)确绞酵ㄐ?，考慮的是可靠性（TCP）；而 RTC 實(shí)時通信，常用于音視頻通話、電話會議，考慮的是低延時（UDP）。

M3U8/TS 是 HLS 協(xié)議的封裝格式，分別表示播放列表文件和資源分片文件。.m3u8 的索引文件 是一個播放列表文件，且文件編碼必須是 UTF-8 格式。TS 流最早應(yīng)用于數(shù)字電視領(lǐng)域，包含十幾個配置信息項(xiàng)，TS 流中的視頻格式是 MPEG-2 TS。Apple 公司推出的 HLS 協(xié)議對 MPEG-2 TS 流做了精減，只保留了兩個最基本的配置表 PAT 和 PMT，再加上音視頻數(shù)據(jù)流就形成了現(xiàn)在的 HLS 協(xié)議，即由 PAT + PMT + TS 數(shù)據(jù)流組成。其中，TS 數(shù)據(jù)中的視頻數(shù)據(jù)采用 H.264/H.265 編碼，而音頻數(shù)據(jù)采用 AAC/MP3 編碼。

#EXTM3U
#EXT-X-VERSION:3             // 版本信息
#EXT-X-TARGETDURATION:11     // 每個分片的最大時長
#EXT-X-MEDIA-SEQUENCE:0      // 分片起始編號，不設(shè)置默認(rèn)為 0
#EXTINF:10.5,                // 第一個分片實(shí)際時長
index0.ts                    // 第一個分片文件資源路徑
#EXTINF:9.6,                 // 第二個分片實(shí)際時長
index1.ts                    // 第二個分片文件資源路徑

FLV 是 RTMP 的媒體封裝協(xié)議，由 FLV Header 和 RTMP 數(shù)據(jù)構(gòu)成。FLV 文件是一種流式文件格式，意味著任何音視頻數(shù)據(jù)都能隨時添加到文件末尾，而不會破壞整體結(jié)構(gòu)。像 MP4、MOV 等媒體封裝格式都是結(jié)構(gòu)化的，即音頻數(shù)據(jù)和視頻數(shù)據(jù)是單獨(dú)存放。與其他主流直播協(xié)議相比，F(xiàn)LV 均具有不可替代的優(yōu)勢。與 HLS 技術(shù)相比，RTMP 協(xié)議在傳輸時延上要比 HLS 小得多；相對于 RTP 協(xié)議，RTMP 底層是基于 TCP 協(xié)議的，所以它不用考慮數(shù)據(jù)丟包、亂序、網(wǎng)絡(luò)抖動等問題；與 WebRTC 技術(shù)相比，對于實(shí)時性要求并沒有那么高的傳統(tǒng)直播來說，RTMP 協(xié)議具有更好的音視頻服務(wù)質(zhì)量。FLV 也因此特別適用于涉及錄制的相關(guān)應(yīng)用場景。

流媒體協(xié)議

• RTMP Streaming: The Real-Time Messaging Protocol Explained
• RTSP: The Real-Time Streaming Protocol Explained

HLS（HTTP Live Streaming）是 Apple 公司提出的基于 HTTP 的流媒體網(wǎng)絡(luò)傳輸協(xié)議，QuickTime X 和 iPhone 軟件系統(tǒng)的一部分，由三部分組成：HTTP、M3U8、TS，其中 HTTP 是傳輸協(xié)議，M3U8 是索引文件，TS 是音視頻的媒體信息。工作原理是把整個流根據(jù)索引文件（.m3u8）分成一個個小的基于 HTTP 的切片文件（.ts），每次只下載一些切片。當(dāng)媒體流正在播放時，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應(yīng)不同的數(shù)據(jù)速率。在開始一個流媒體會話時，客戶端會下載一個包含元數(shù)據(jù)的擴(kuò)展 M3U 播放視頻文件列表，用于尋找可用的媒體流 TS 切片。HLS 只請求基本的 HTTP 報文，與實(shí)時傳輸協(xié)議 RTP 不同，HLS 可以穿過任何允許 HTTP 數(shù)據(jù)通過的防火墻或者代理服務(wù)器。

RTMP（Real Time Messaging Protocol）是基于 TCP 的流媒體網(wǎng)絡(luò)傳輸協(xié)議，設(shè)計初衷是服務(wù)于流媒體服務(wù)器和 Adobe Flash Player 之間的音視頻數(shù)據(jù)傳輸。因?yàn)槭墙⒃?TCP 長連接協(xié)議的基礎(chǔ)上，所以客戶端向服務(wù)端推流這些操作的延時性很低約 5s。至于 HLS 起播理論上至少需要 1 個 TS 切片，而切片大小通常會在 10s 左右，因此延時也至少在 10s 以上，實(shí)際延時會在 20~30s，這是由于 HLS 使用的是 HTTP 短連接，頻繁的處理握/揮手造成延遲比較久的現(xiàn)狀。但 Apple 公司認(rèn)為 RTMP 協(xié)議在安全方面有重要缺陷，所以 iOS 不支持該協(xié)議，在 Apple 公司的不斷施壓下， Adobe 已經(jīng)停止對 RTMP 協(xié)議的更新。

RTSP（Real Time Streaming Protocol）是基于 RTP 的流媒體網(wǎng)絡(luò)傳輸協(xié)議，在基于 HTTP 的自適應(yīng)比特率流媒體協(xié)議出現(xiàn)前，同 RTMP 一起主導(dǎo)互聯(lián)網(wǎng)流媒體領(lǐng)域，是實(shí)時監(jiān)控和事件檢測解決方案的最佳選擇。現(xiàn)在主要應(yīng)用于網(wǎng)絡(luò)攝像機(jī)（IP Camera）以及其他依賴視頻源的 IoT 設(shè)備，常見的是監(jiān)控和閉路電視。

MPEG-DASH（Dynamic Adaptive Streaming over HTTP）是一種自適應(yīng)比特率流技術(shù)，基于 HTTP 的動態(tài)自適應(yīng)流使高質(zhì)量流媒體在互聯(lián)網(wǎng)傳輸。與 HLS 類似，MPEG-DASH 也將內(nèi)容分解成一系列小型的基于 HTTP 的文件片段，每個片段包含很短長度的可播放內(nèi)容，而總長度可能長達(dá)數(shù)小時。

• M3U - MP3 URL，是一種播放多媒體列表的文件格式，最初是為播放 MP3 等音頻文件，但現(xiàn)在越來越多的被用來播放視頻文件列表。M3U8 是 Unicode 版本的 M3U，用 UTF-8 編碼。
• RTP - Real-time Transport Protocol，實(shí)時傳輸協(xié)議通常使用 UDP 傳輸，部分場景也能使用 TCP。

場景應(yīng)用

人審業(yè)務(wù)

• 音量均衡可行性論證
• Web 端音量均衡實(shí)現(xiàn)和應(yīng)用

上面介紹 RTMP 和 HLS 協(xié)議的優(yōu)劣勢。盡管 RTMP 協(xié)議已不再更新，但目前沒有更好的協(xié)議能取代它的價值，因此其仍在業(yè)界受到廣泛應(yīng)用，主要用于解決“第一公里”問題。就兩者特點(diǎn)而言，應(yīng)用場景通常做出如下分工：

• 推流使用 RTMP 協(xié)議，延遲低，推流穩(wěn)定；
• 流媒體系統(tǒng)內(nèi)部分發(fā)使用 RTMP 協(xié)議，網(wǎng)絡(luò)狀況好的情況下 TCP 長鏈接能更高效的傳輸；
• PC 基本都安裝有 Flash，因此使用 RTMP 協(xié)議，而移動端的網(wǎng)頁播放器以及 iOS 設(shè)備使用 HLS 協(xié)議；
• 點(diǎn)播場景無延時要求，推薦使用 HLS 協(xié)議，直播場景有延時要求，推薦使用 RTMP 協(xié)議。

目前字節(jié)跳動采用的統(tǒng)一方案是直播回放流（點(diǎn)播）采用 HLS 協(xié)議，直播實(shí)時流（直播）采用 FLV 協(xié)議，而短視頻這類非流媒體則采用 MP4 封裝協(xié)議。

針對人審業(yè)務(wù)，除了基礎(chǔ)的播放能力，為提高審核體驗(yàn)，陸續(xù)推出包括不限于以下音視頻輔助能力：

• 發(fā)言者標(biāo)識，RTC 在推流時會往視頻幀內(nèi)添加 SEI 補(bǔ)充增強(qiáng)信息（位于 NAL 層），能夠獲取直播連麥的嘉賓位置、麥克風(fēng)狀態(tài)、攝像頭狀態(tài)等媒體信息。通過在審核側(cè)還原客戶端交互行為，提高處罰準(zhǔn)確性以及預(yù)防組合違規(guī)風(fēng)險。
• 主備流切換，當(dāng)前容災(zāi)技術(shù)較為成熟，直播推流普遍也有多個 CDN 廠商。審核側(cè)直播回放流采用 HLS 的方式存儲，而不同 CDN 廠商對于 TS 切片大小的規(guī)范不完全相同。所以在實(shí)現(xiàn)主備流切換的同時，還需要對流切片，以保持主備流內(nèi)容和時長的一致性。
• 音量均衡，審核員需要長時間面對音視頻進(jìn)行審核，在過勞疲憊的狀態(tài)下，聲音的陡變會影響審核員的工作體驗(yàn)和身心健康。通過對單幀音頻（Comperssor）或音頻響度（Online Norm）進(jìn)行調(diào)整，以期達(dá)到音量均衡的效果?？紤]到直播回放流無法在進(jìn)審時拿到原始音頻數(shù)據(jù)，因此只能采取 Comperssor 算法去動態(tài)設(shè)置DynamicsCompressorNode的參數(shù)。

直播業(yè)務(wù)

• 斗魚 H5 直播原理解析
• 深入分析各行業(yè)直播方案與原理
• A simple RTCDataChannel sample

以下技術(shù)調(diào)研截止至 2024 年 8 月29 日，且僅限于各大平臺的網(wǎng)頁版。

國內(nèi)的部分直播平臺如斗魚、虎牙、B 站等，其實(shí)時直播技術(shù)主要分為 HLS（M3U8/TS）和 RTMP（FLV）兩種。斗魚采用的是在 HTTP-FLV 技術(shù)基礎(chǔ)上的優(yōu)化方案，在網(wǎng)絡(luò)請求中能夠搜索到.xs文件。虎牙的網(wǎng)絡(luò)請求里僅存在一份 M3U8 文件以及后續(xù)的若干 TS 切片，屬于較為成熟的 HLS 成套解決方案。而 B 站則是多份 M3U8 文件以及后續(xù)的若干 M4S 切片，這是經(jīng)過格式轉(zhuǎn)換的 HLS 技術(shù)優(yōu)化方案。

斗魚直播

虎牙直播

B 站直播

斗魚直播間其實(shí)并沒有找到.flv的網(wǎng)絡(luò)請求（首頁推薦直播流能搜到），而是找到.xs的網(wǎng)絡(luò)請求。這是因?yàn)槎肤~默認(rèn)不完全使用 HTTP 去拉流，而是采用 CDN 和 P2P 兩種方式同時去拉流，.xs并不是一個完整的 FLV 流，而是一個子 FLV 流。

斗魚直播間 WebRTC 鏈接

虎牙直播間 WebRTC 鏈接

B 站首頁 WebRTC 鏈接

B 站直播間 WebRTC 鏈接

斗魚的 P2P 是基于 WebRTC 的 DataChannel，在打開首頁或直播頁面時，能夠看到眾多的 WebRTC 連接。B 站的聊天文字甚至?xí)戎辈ギ嬅娓绯霈F(xiàn)，并且可以看到觸發(fā) createDataChannel 的事件，然而首頁（僅有直播流，沒有彈幕和聊天室）則不存在該事件?；⒀赖牧奶煳淖殖霈F(xiàn)有所延遲，建立 WebRTC 鏈接也存在一定的時延，其首頁情況與 B 站大致相同。

綜合上述調(diào)研結(jié)論，能夠推斷斗魚直播的 WebRTC 確實(shí)運(yùn)用在拉流；B 站直播和虎牙直播則主要運(yùn)用在聊天和彈幕。

實(shí)時會議

• 騰訊會議如何構(gòu)建實(shí)時視頻傳輸算法架構(gòu)
• TRTC 實(shí)踐，音視頻互動 Demo、即時通信 IM 服務(wù)搭建
• RTC 技術(shù)的試金石：火山引擎視頻會議場景技術(shù)實(shí)踐

2011 年，Google 先后收購 GIPS 和 On2，組成 GIPS 音視頻引擎 + VPx 系列視頻編解碼器，并將其代碼開源，WebRTC 項(xiàng)目應(yīng)運(yùn)而生。次年 Google 將 WebRTC 集成到 Chrome 瀏覽器中，從而為瀏覽器實(shí)現(xiàn)音視頻通信提供了可能。

國內(nèi)主流 toB 辦公軟件：字節(jié)、阿里、騰訊的視頻會議都是基于 WebRTC 及其擴(kuò)展，主要在點(diǎn)對點(diǎn)通信（語音通話、視頻通話）、電話會議（飛書會議、釘釘會議、騰訊會議）、屏幕共享（實(shí)時共享屏幕）運(yùn)用到該技術(shù)。

在附文“騰訊會議如何構(gòu)建實(shí)時視頻傳輸算法架構(gòu)”騰訊強(qiáng)調(diào)自 QQ 時代起，在音視頻實(shí)時傳輸系統(tǒng)的搭建與優(yōu)化方面已有多年積累，并重新編寫了一個跨平臺而且高效的引擎-xCast，引擎之間以 Pere 作為網(wǎng)絡(luò)層傳輸協(xié)議。結(jié)合附文“TRTC 實(shí)踐，音視頻互動 Demo、即時通信 IM 服務(wù)搭建”。xCast-Pere 的架構(gòu)目前僅在騰訊會議生態(tài)間支持傳輸與解析，當(dāng)數(shù)據(jù)到達(dá)媒體服務(wù)器后會在轉(zhuǎn)碼服務(wù)器里轉(zhuǎn)換為 SIP、TencentRTC 或 WebRTC 進(jìn)行傳輸。

伴隨著疫情居家辦公的歷史背景推動下，目前主流會議軟件的功能都已經(jīng)非常成熟，諸如自由開麥、自由布局、屏幕共享、Web 入會等交互能力層出不窮，而針對弱網(wǎng)、弱設(shè)備、噪聲、弱光線等極端環(huán)境的解決方案也日益完善。未來，分組會議、3D 空間音效、千方會議、智能會議也會逐漸成為我們的日常。

環(huán)境創(chuàng)造需求，需求推動技術(shù)。音視頻技術(shù)已完成筑基，讓我們無限期待創(chuàng)造力的誕生！