基礎知識

音頻基礎

聲音轉數字信號

音頻基礎知識及 PCM 技術詳解

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

1. 聲波通過空氣傳播到麥克風的振膜。
2. 振膜隨空氣抖動的振幅大小產生相應的電學信號，即模擬信號（Analogue Signal）。
3. 通過模數轉換器 ADC 將模擬信號轉換成數字信號（Digital Signal）。

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

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

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

音頻壓縮

編碼之 AAC 解析

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

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

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

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

視頻基礎

編碼原理

• 理解視頻編解碼技術
• 音視頻h264編碼介紹

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

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

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

一個相當典型的 30 分鐘視頻會議需要大約 447.9 GB 的存儲空間，而一部 2 小時的電影需要幾乎 1.79 TB（即 1790 GB）的空間。

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

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

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

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

視頻壓縮

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

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

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

幀間壓縮，亦稱為時間壓縮。其主要通過對時間軸上不同幀之間的數據進行比較從而實現壓縮。幀間壓縮一般是無損的，其中幀差值算法是一種典型的時間壓縮方法。該算法通過對比本幀與相鄰幀之間的差異，僅記錄本幀與其相鄰幀的差值信息。這樣一來，就能夠大大減少數據量，因為在很多情況下，相鄰幀之間的變化往往是局部的、微小的，只需要記錄這些變化部分，在播放時結合相鄰幀的信息即可還原出當前幀的畫面，從而實現高效的視頻壓縮。

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

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

碼流結構

• H.264碼流結構
• 音視頻基礎：H265/HEVC&碼流結構
• H.265 如何比 H.264 提升 40% 編碼效率

從碼流功能角度分為 NAL 層和 VCL 層。NAL 網絡抽象層負責以網絡所要求的恰當的方式對數據進行打包和傳送。VCL 視頻編碼層包括核心壓縮引擎和塊，宏塊和片的語法級別定義，設計目標是盡可能地獨立于網絡進行高效的編碼。

從碼流功能角度可分為 NAL（網絡抽象層） 和 VCL（視頻編碼層） 。

NAL 負責以網絡所要求的恰當方式對數據進行打包和傳送。它能夠根據不同的網絡環境和傳輸需求，對視頻編碼數據進行有效的封裝和處理，確保數據能夠在各種網絡條件下穩定傳輸。

VCL 則包括核心壓縮引擎以及塊、宏塊和片的語法級別定義。其設計目標是盡可能地獨立于網絡進行高效的編碼。VCL 專注于視頻內容的壓縮編碼，通過各種先進的編碼技術去除視頻中的冗余信息，以實現高壓縮比和良好的圖像質量。

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

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

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

H.264/AVC Macroblocks

H.265/HEVC Macroblocks

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

優化算法

音頻優化

音頻去噪

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

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

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

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

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

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

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

回聲消除

AEC 背景介紹

產生回聲的原因是聲音信號經過一系列反射之后再次被錄進麥克風。通信系統的回聲主要分為兩類：電路回聲和聲學回聲。

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

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

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

音量均衡

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

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

音量均衡 前的波形圖

音量均衡 后的波形圖

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

等響曲線圖

過去，工程師們常常結合使用峰值表、VU 表以及他們的耳朵來確定音軌的真實感知響度，然而，這種方式存在一定的局限性。2000 年，Katz 提出了一種 K-Metering 的計量標準，該標準將過去的最佳概念與當前的心理聲學相結合。雖然不同類型的音樂需要不同的動態余量，但這種方式能夠將音樂的平均水平標準化。在此基礎上，將 K-Metering 進一步完善后，現代標準計量方法 LKFS 被國際電信聯盟（ITU）制定并發布，從而實現了視頻格式音頻電平的標準化。如今，大多數廣播、電影和視頻游戲公司都采用 LKFS 作為測量響度的標準。LKFS 的采用使得音頻制作和播放更加規范和統一，有助于提高音頻質量和用戶體驗。同時，它也為不同平臺和設備之間的音頻兼容性提供了保障。

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

空間音頻

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

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

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

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

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

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

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

視頻優化

碼控算法

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

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

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

碼率控制器負責收集碼率、延時和緩沖區狀態信息并調節編碼參數，使得性能指標維持在給定水平上。緩沖區起平滑碼率波動的作用。在編碼端，數據輸入緩沖區的碼率是變化的，而輸出碼率則取決于碼率控制的模式。

幀層碼率控制根據網絡帶寬、緩存占用量、緩存大小及剩余比特來分配每一幀的目標比特；基本單元層碼率控制目標比特由該幀的剩余目標比特平均得到。

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

不同類型的視頻資源對于畫面質量和碼率穩定性的權重不同。

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

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

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

Jitter Buffer

• Jitter Buffer
• WebRTC-QOS之JitterBuffer詳解

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

網絡抖動是指網絡傳輸數據時，在數據包到達接收方之前，網絡傳輸所引起的延遲波動或數據包丟失現象，產生原因包括：

1. 傳輸路徑，上一時刻的路由發生故障，數據包路徑變更導致端到端的傳輸時長發生改變；
2. 網絡擁塞，分組交換網絡中傳送分組的數目太多時，由于存儲轉發節點的資源有限而造成網絡傳輸性能下降的情況，常伴隨數據丟失、時延增加、吞吐量下降，嚴重時甚至會導致“擁塞崩潰”。
3. 擁塞控制，慢啟動、擁塞避免、快重傳、快恢復等手段帶來的額外抖動。

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

可伸縮編碼

H.264可伸縮編碼 SVC

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

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

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

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

行業標準

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

編碼協議

• 網頁音頻編碼指南
• 網頁視頻編碼指南
• 國內外視頻編解碼標準體系
• 音視頻基礎-視頻編碼

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

不同組織主導制定的視頻編碼協議，常見的包括 3 大類：

• ISO-MPEG / ITU-T 系列，由國際標準組織機構（ISO）下屬的運動圖象專家組（MPEG）和國際電傳視訊聯盟遠程通信標準化組織（ITU-T）開發的系列編碼標準。
• AOM 系列，前身是由 Google 內部使用的 VPx 系列的編碼標準。后續 Microsoft、Netflix 等多家科技巨頭加入組建成立開放媒體聯盟（Alliance for Open Media，AOM）。
• AVS 系列，數字音視頻編解碼技術標準（Audio Video coding Standard）是國內具備自主知識產權的信源編碼標準體系。

ISO-MPEG / ITU-T 系列

Publicly Available Standards

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

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

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

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

ITU-T 在 1990 年最先研究出 H.261，這是第一個實用化國際標準，后來在 1995 年和 1996 年先后發布 H.262、H.263，指導后來的H視頻編解碼器，這是ITU-T的H26x系列。

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

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

2018 年 MPEG 和 VCEG 成立的聯合視頻探索小組（JVET）開始將 H.266/VVC 標準化。新標準要求在相同的體驗質量的前提下，同 H.265/HEVC 相比，壓縮率優化 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+ 步高動態范圍 (HDR)；輔助通道，如深度通道、阿爾法通道等；從 0 到 120 Hz 的可變幀率；具有時間（幀速率變化）和空間（分辨率變化）可伸縮性的可伸縮編碼；SNR、立體/多視圖編碼、全景格式和靜止圖像編碼。

AOM 系列

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

由于 H.26X 相關標準都是收費的，崇尚開源的 Google 聯合 Amazon、Cisco、Intel、Microsoft、Mozilla 以及 Netflix 等互聯網巨頭成立開放媒體聯盟（Alliance for Open Media），旨在通過制定全新、開放、免版權費的視頻編碼標準和視頻格式。

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

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

AVS 系列

• 數字音視頻編解碼技術標準工作組
• 一文讀懂AVS的發展歷程、關鍵技術及應用展望

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

AVS 是一套包含系統、視頻、音頻、數字版權管理在內的完整標準體系。我國牽頭制定的、技術先進的第二代信源編碼標準；領導國際潮流的專利池管理方案，完備的標準工作組法律文件；制定過程開放、國際化。

AVS 產品形態包括：1）芯片：高清晰度/標準清晰度 AVS 解碼芯片和編碼芯片，國內需求量在未來十多年的時間內年均將達到 4000 多萬片；2）軟件：AVS 節目制作與管理系統，Linux 和 Window 平臺上基于 AVS 標準的流媒體播出、點播、回放軟件；3）整機：AVS 機頂盒、AVS 硬盤播出服務器、AVS 編碼器、AVS 高清晰度激光視盤機、AVS 高清晰度數字電視機頂盒和接收機、AVS 手機、AVS 便攜式數碼產品等。

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

點播協議

MP4 格式詳解

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

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

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

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

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

OGV 文件格式是以 Ogg 容器格式保存的視頻文件，它包含可能使用一種或多種不同編解碼器的視頻流，例如Theora，Dirac 或 Daala。可以使用各種媒體播放器來播放 OGV 文件。OGV 文件通常用于使用HTML5 <video>標簽播放網頁視頻內容。但是，即使文件包含視頻內容，它們也通常在HTML源代碼中使用 ".ogg" 擴展名進行引用。

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

WebM 是一種開放、免費的多媒體容器格式，用于存儲視頻、音頻和字幕等數據。WebM 格式由 Google 公司開發，使用 VP8 視頻編解碼器和 Vorbis 音頻編解碼器，可以在大多數現代網絡瀏覽器上進行播放，旨在為網絡上的 HTML5 視頻提供一個高效的開放標準。

直播協議

• WebRTC 入門教程
• 實時傳輸 Web 音頻與視頻

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

會議直播亦稱為實時互動直播，以 WebRTC 協議為主；娛樂直播亦稱為傳統直播，以 RTMP 和 HLS 協議為主。

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

WebRTC 是 RTC 在 Web 的一種實現形式，適用于各種實時通信場景，包括：點對點通訊，支持瀏覽器之間進行音視頻通話，例如語音通話、視頻通話等；電話會議，支持多人音視頻會議，例如騰訊會議、釘釘會議等；屏幕共享，支持實時共享屏幕；直播，用于構建實時直播，用戶可以通過瀏覽器觀看直播內容。IM 即時通信，常用于文字聊天、語音消息發送、文件傳輸等方式通信，考慮的是可靠性（TCP）；而 RTC 實時通信，常用于音視頻通話、電話會議，考慮的是低延時（UDP）。

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

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

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

流媒體協議

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

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

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

RTSP（Real Time Streaming Protocol）是基于 RTP 的流媒體網絡傳輸協議，在基于 HTTP 的自適應比特率流媒體協議出現前，同 RTMP 一起主導互聯網流媒體領域，是實時監控和事件檢測解決方案的最佳選擇。現在主要應用于網絡攝像機（IP Camera）以及其他依賴視頻源的 IoT 設備，常見的是監控和閉路電視。

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

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

場景應用

人審業務

• 音量均衡可行性論證
• Web 端音量均衡實現和應用

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

• 推流使用 RTMP 協議，延遲低，推流穩定；
• 流媒體系統內部分發使用 RTMP 協議，網絡狀況好的情況下 TCP 長鏈接能更高效的傳輸；
• PC 基本都安裝有 Flash，因此使用 RTMP 協議，而移動端的網頁播放器以及 iOS 設備使用 HLS 協議；
• 點播場景無延時要求，推薦使用 HLS 協議，直播場景有延時要求，推薦使用 RTMP 協議。

目前字節跳動采用的統一方案是直播回放流（點播）采用 HLS 協議，直播實時流（直播）采用 FLV 協議，而短視頻這類非流媒體則采用 MP4 封裝協議。

針對人審業務，除了基礎的播放能力，為提高審核體驗，陸續推出包括不限于以下音視頻輔助能力：

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

直播業務

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

以下技術調研截止至 2024 年 8 月29 日，且僅限于各大平臺的網頁版。

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

斗魚直播

虎牙直播

B 站直播

斗魚直播間其實并沒有找到.flv的網絡請求（首頁推薦直播流能搜到），而是找到.xs的網絡請求。這是因為斗魚默認不完全使用 HTTP 去拉流，而是采用 CDN 和 P2P 兩種方式同時去拉流，.xs并不是一個完整的 FLV 流，而是一個子 FLV 流。

斗魚直播間 WebRTC 鏈接

虎牙直播間 WebRTC 鏈接

B 站首頁 WebRTC 鏈接

B 站直播間 WebRTC 鏈接

斗魚的 P2P 是基于 WebRTC 的 DataChannel，在打開首頁或直播頁面時，能夠看到眾多的 WebRTC 連接。B 站的聊天文字甚至會比直播畫面更早出現，并且可以看到觸發 createDataChannel 的事件，然而首頁（僅有直播流，沒有彈幕和聊天室）則不存在該事件。虎牙的聊天文字出現有所延遲，建立 WebRTC 鏈接也存在一定的時延，其首頁情況與 B 站大致相同。

綜合上述調研結論，能夠推斷斗魚直播的 WebRTC 確實運用在拉流；B 站直播和虎牙直播則主要運用在聊天和彈幕。

實時會議

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

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

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

在附文“騰訊會議如何構建實時視頻傳輸算法架構”騰訊強調自 QQ 時代起，在音視頻實時傳輸系統的搭建與優化方面已有多年積累，并重新編寫了一個跨平臺而且高效的引擎-xCast，引擎之間以 Pere 作為網絡層傳輸協議。結合附文“TRTC 實踐，音視頻互動 Demo、即時通信 IM 服務搭建”。xCast-Pere 的架構目前僅在騰訊會議生態間支持傳輸與解析，當數據到達媒體服務器后會在轉碼服務器里轉換為 SIP、TencentRTC 或 WebRTC 進行傳輸。

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

環境創造需求，需求推動技術。音視頻技術已完成筑基，讓我們無限期待創造力的誕生！