音視訊知識圖譜 2022.04

前些時間，我在知識星球上建立了一個音視訊技術社群： 關鍵幀的音視訊開發圈 ，在這裡群友們會一起做一些打卡任務。比如：週期性地整理音視訊相關的面試題，彙集一份 音視訊面試題集錦 ，你可以看看 《音視訊面試題集錦 2022.04》 。再比如：循序漸進地歸納總結音視訊技術知識，繪製一幅 音視訊知識圖譜 。

下面是 2022.04 月知識圖譜新增的內容節選：

1）圖譜路徑： 採集/音訊採集/聲音三要素/響度

• 主觀計量

• 響度，反映人耳感受到的聲音強弱。

• 響度級，兩個聲音在聽覺上認為是相同的響度時，就可以把 1000 Hz 純音的這個聲壓級規定為該頻率純音的「響度級」。單位：方（Phon）。

• 客觀計量

• 聲能，聲音在介質中傳播時，使媒介附加的能量。質點振動動能和質點偏離平衡位置所具有的勢能的總和。單位：瓦。

• 聲強，單位時間內通過垂直於聲波傳播方向的單位面積的平均聲能。單位：瓦/平方米。

• 聲強級，人耳允許的聲強範圍太大；心理物理學的研究表明，人對聲音強弱的感覺並不是與聲強成正比，而是與其對數成正比。因此引入「聲強級」。

• 聲壓，聲波通過媒質時，由振動所產生的壓強改變數。單位：牛頓/平方米、帕斯卡。實際中更多使用聲壓來代表聲波的振幅表現：人耳表現為壓力敏感組織；壓力或壓強具有相對容易進行實地測量。

• 聲壓級，人耳允許的聲壓範圍太大；人對聲音的強弱的感覺是與聲壓的對數成正比。因此引入「聲壓級」。通常我們說聲音大小有多少分貝，說的就是「聲壓級」。

2）圖譜路徑： 採集/音訊採集/聲音三要素/音調

• 主觀計量

• 音調，人耳對聲音高低的主觀感受。單位：美（mel）。取頻率 1000Hz、聲壓級為 40 分貝的純音的音調作標準，稱為 1000 美。另一些純音，聽起來調子高一倍的稱為 2000 美，調子低一倍的稱為 500 美，依此類推，可建立起整個可聽頻率內的音調標度。

• 科學音調記號法，兩個音符之間若頻率相差整數倍，則聽起來非常相似。因此，我們將這些音放在同一個「音調集合」中。兩個音符間若相差一倍的頻率，則我們稱兩者之間相差一個八度。

• 客觀計量

• 頻率，聲音振動的快慢。單位：赫茲。

3）圖譜路徑： 採集/音訊採集/聲音數字化/取樣率

• 奈奎斯特取樣定理：一般實際應用中保證取樣頻率為訊號最高頻率的 2.56～4 倍。

• 人類發聲在 5kHz 內，聽覺範圍是 20～20kHz 內。數字音訊的取樣率需要在 40k 以上。

• 44100Hz 由來：最早的數字錄音由一臺錄影機加上一部 PCM 編碼器製作的，由於當時使用的是 PAL 錄影制式(帕制，與之對應的有 NTSC)，場頻 50 Hz，可用掃描線數 294 條，一條視訊掃描線的磁跡中記錄 3 個音訊資料塊，把它們相乘，就得到了 44100 這個奇葩數字。

4）圖譜路徑： 採集/音訊採集/聲音數字化/量化位深

• 對模擬音訊訊號的幅度軸進行數字化，它決定了模擬訊號數字化以後的動態範圍。

• 8 bit 位深對應 48 分貝的動態範圍（最大聲壓級 = 20 * lg(2^8) = 48.16），16 bit 位深對應 96 分貝的動態範圍，24 bit 位深對應 144 分貝的動態範圍。

5）圖譜路徑： 採集/視訊採集/影象/顏色模型

• CIE RGB 顏色模型：基於人眼視覺感知三原色理論，CIE 通過大量實驗資料建立了 RGB 顏色模型，標準化了 RGB 表示。

• CIE XYZ 顏色模型：為了解決 RGB 模型中與負光混合所帶來的種種問題，CIE 從數學上定義了三種標準基色 XYZ，形成了 CIE XYZ 顏色模型。

• NTSC YIQ 顏色模型：在模擬電視時代，RGB 工業顯示器要求一幅彩色影象由分開的 R、G、B 訊號組成，而電視顯示器則需要混合訊號輸入，為了實現對這兩種標準的相容，NTSC 基於 XYZ 模型制定了 YIQ 顏色模型，實現了彩色電視和黑白電視的訊號相容。

• PAL YUV 顏色模型：為了解決 NTSC YIQ 的組合模擬視訊訊號中分配給色度資訊的頻寬較低而影響了影象顏色質量的問題，PAL 引入了 YUV 顏色模型，支援用不同的取樣格式來調整傳輸的色度資訊量。

• ITU-R YCbCr 顏色模型：進入數字電視時代，ITU-R 為數字視訊轉換制定了 YCbCr 顏色模型，成為我們現在最常使用的顏色模型。

• 伽馬校正：在早年 CRT 顯示器流行的年代，我們遇到了顯示伽馬問題，從而引入了伽馬校正過程並延用至今。

6）圖譜路徑： 採集/視訊採集/紋理/資料與紋理轉換/紋理轉資料（GPU → CPU）/Android 方案

• glReadPixels

• OpenGL ES 2.0 和 3.0 均支援，相容性較好。

• 會影響 CPU 時鐘週期，同時 GPU 會等待當前幀繪製完成，讀取畫素完成之後，才開始下一幀的計算，造成渲染管線停滯。

• 讀取的是當前繫結 FBO 的顏色緩衝區影象，所以當使用多個 FBO（幀緩衝區物件）時，需要確定好我們要讀那個 FBO 的顏色緩衝區。

• 在大解析度影象的讀取時效能略差。目前通用的優化方法是在 shader 中將處理完成的 RGBA 轉成 YUV （一般是 YUYV 格式），然後基於 RGBA 的格式讀出 YUV 影象，這樣傳輸資料量會降低一半，效能提升明顯。

• PBO（Pixel Buffer Object，畫素緩衝區物件）

• OpenGL ES 3.0 才支援，在 Android 上有相容性問題。

• PBO 類似於 VBO（頂點緩衝區物件），開闢的也是 GPU 快取，而儲存的是影象資料。PBO 不連線到紋理，且與 FBO （幀緩衝區物件）無關。

• PBO 可以在 GPU 的快取間快速傳遞畫素資料，不影響 CPU 時鐘週期，支援非同步，主要用於非同步畫素傳輸。

• 以空間換時間，通常需要多個 PBO 交替配合使用來提升效能。

• ImageReader

• ImageReader 是 Android SDK 提供的 Java 層物件，其內部會建立一個 Surface 物件。

• EGL 建立 OpenGL 上下文環境時，eglCreateWindowSurface 需要傳入 ANativeWindow 物件，而 ANativeWindow 又基於 Surface 物件建立的。可以利用 ImageReader 物件的 Surface 物件作為 OpenGL 展示渲染結果的 Window Surface ，每次渲染的結果可以通過 ImageReader 物件的回撥獲取。

• HardwareBuffer

• 一個更底層的物件，代表可由各種硬體單元（GPU、感測器或上下文集線器或其他輔助處理單元）訪問的緩衝區。Native 層叫 AHardwareBuffer，AHardwareBuffer 讀取視訊記憶體（紋理）影象資料時，需要與 GLEXT 和 EGLEXT 配合使用。

• HardwareBuffer 是 Android 8 API >= 26 提供的用於替換 GraphicBuffer 的介面，在 API <= 25 時可以使用 GraphicBuffer。兩者在使用步驟上基本一致，均可以用於快速讀取視訊記憶體（紋理）影象資料，但是 HardwareBuffer 還可以訪問其他硬體的儲存器，使用更廣泛。

• 效能和實現選擇

• 大解析度情況，ImageReader、PBO、HardwareBuffer 明顯優於 glReadPixels 方式。一般 HardwareBuffer、ImageReader、PBO 三種方式效能相差不大，HardwareBuffer 理論上效能最優。

• Native 層建議選擇 PBO 方式，超大解析度建議嘗試 HardwareBuffer 方式，Java 層建議使用 ImageReader 方式。

如果你也對音視訊技術感興趣，比如，符合下面的情況：

• 在校大學生 → 學習音視訊開發

• iOS/Android 客戶端開發 → 轉入音視訊領域

• 直播/短視訊業務開發 → 深入音視訊底層 SDK 開發

• 音視訊 SDK 開發 → 提升技能，解決優化瓶頸

可以長按識別或掃描下面二維碼，瞭解一下這個社群，根據自己的情況按需加入：

下面是 2022.04 月的知識圖譜新增內容快照（圖片被平臺壓縮不夠清晰，可以加文章後面微信索要清晰原圖）：