CBR vs VBR 深度解析：影片編碼的位元速率控制演算法

為什麼同樣是 1080p、同樣 30 秒的影片，有些檔案 50MB，有些卻只要 5MB？差異的關鍵並不在於解析度或幀率，而在於**位元速率控制（Bitrate Control）**的演算法選擇。

身為 Squishyfile 的開發團隊，我們每天都在處理一個核心技術問題：「編碼器（Encoder）要如何決定每一秒、每一個影格（Frame）該分配多少資料量，才能在達成使用者設定的目標檔案大小（Target File Size）時，不破壞影像的結構完整性？」

這篇文章將從編碼器底層的視角，拆解 CBR（Constant Bitrate） 與 VBR（Variable Bitrate） 兩大速率控制機制，並說明為什麼 Squishyfile 在提供「自訂檔案大小（Custom Size）」功能時，必須採用多遍次（Multi-Pass）的 VBR 策略。

Rate Control（速率控制）是什麼？

在影片編碼領域，Rate Control 指的是編碼器對輸出資料流（Output Bitstream）的位元速率進行主動調節的機制。它的核心目標只有一個：

> 在給定的位元預算（Bit Budget）內，找到檔案大小（File Size）與視覺品質（Visual Quality）之間的最佳平衡點。

舉例來說，如果你要求編碼器把一部 100MB 的影片壓到 10MB，編碼器必須「決定」哪些影格值得保留較多資料、哪些影格可以透過較高的量化等級（Quantization Level）來壓縮。這個「決策過程」就是 Rate Control 的職責。

在 FFmpeg 的 libx264 與 libx265 中，Rate Control 模組會綜合考量以下參數：

量化參數（QP, Quantization Parameter）：控制壓縮強度，QP 越高，畫質損失越大。
緩衝區模型（VBV/HRD Buffer）：確保位元流不會超過解碼端的緩衝上限。
場景複雜度分析（Scene Complexity Analysis）：評估影格內的細節量與動態範圍。

CBR（Constant Bitrate，固定位元速率）

運作原理

CBR 是一種「強制均分」策略。編碼器會試圖讓每一秒鐘的影片都維持在固定的位元速率，例如 5Mbps。無論畫面是靜態的簡報投影片，還是充滿粒子特效的動作場景，編碼器都會盡量把資料量「塞滿」或「削減」到目標數值。

在底層實作上，CBR 會透過即時調整 QP 值來達成目標。當畫面複雜度超過預期時，編碼器被迫提高 QP（增加壓縮率），導致區塊效應（Blocking Artifacts）或蚊式雜訊（Mosquito Noise）；而當畫面過於簡單時，又必須用多餘的資料去「填充」位元預算，造成位元浪費（Bit Waste）。

技術優勢

CBR 的最大價值在於可預測性（Predictability）：

檔案大小容易估算：總長度 × 固定速率 ≈ 最終大小。
解碼負載穩定：播放器不需要處理劇烈的位元流波動，緩衝區管理簡單。
適合即時串流（Livestreaming）與廣播（Broadcasting）：網路頻寬固定時，CBR 能避免突發流量（Traffic Burst）導致的緩衝或斷線。

限制與瓶頸

CBR 的根本缺陷在於它無視內容複雜度：

靜態場景的浪費：例如 10 秒鐘的黑畫面，CBR 仍會持續寫入固定的位元資料，這些位元對畫質毫無貢獻。
動態場景的崩壞：快速移動的畫面或細膩的髮絲紋理，需要大量位元來維持邊緣清晰度。CBR 的固定預算無法應付這種「資料飢渴」，導致畫面糊成一團。

> 工程師觀點：CBR 本質上是一種「時間維度的平均主義」，它犧牲了編碼效率來換取網路傳輸的穩定性。

VBR（Variable Bitrate，動態位元速率）

智慧型資料分配邏輯

與 CBR 相反，VBR 採用「按需分配」策略。編碼器會先分析影格（Frame）或場景（Scene）的視覺複雜度，再動態決定該區段應該獲得多少位元預算。

高複雜度場景（例如煙火爆炸、水花飛濺、快速運鏡）：編碼器提高位元分配，降低 QP，保留細節紋理。
低複雜度場景（例如藍天、白牆、靜態簡報）：編碼器降低位元分配，提高 QP，甚至重用前後影格的區塊（透過 P-Frame / B-Frame 的 Motion Compensation）。

這種機制讓 VBR 在相同的平均位元速率下，能夠提供遠優於 CBR 的視覺品質；或者在相同的畫質水準下，產生更小的檔案。

2-Pass VBR：雙遍次掃描的最佳化策略

在實務上，單遍次（Single-Pass）的 VBR 雖然能動態調整，但編碼器在「當下」並不知道後續場景會有多複雜，容易導致前半段用光預算、後半段被迫粗劣壓縮的情況。

2-Pass VBR 解決了這個問題：

第一遍（Pass 1 - Analysis）：編碼器以極快的速度掃描整部影片，建立「場景複雜度地圖」（Complexity Map）。它記錄每一個影格、每一個巨集區塊（Macroblock）所需的資料量，計算出整部影片的「理想位元預算分配表」。
第二遍（Pass 2 - Encoding）：根據第一遍的分析結果，編碼器進行真正的壓縮。它知道哪裡該「揮霍」位元、哪裡該「節省」，從而在全域（Global）層面達成精準的檔案大小控制。

這正是 Squishyfile「自訂檔案大小（Custom Size）」功能的核心技術基礎。當使用者輸入「請把這部 200MB 的影片壓到 15MB」時，我們的 WASM 編碼引擎會自動觸發 2-Pass VBR 流程：

Pass 1 先計算出 15MB 預算下的「每幀理想 QP 曲線」。
Pass 2 嚴格按照這條曲線執行編碼，確保輸出檔案的大小誤差落在 ±2% 以內，同時讓視覺品質的衰減分佈在最不敏感的區域。

VBR 的應用場景

檔案儲存與歸檔：在硬碟或雲端空間有限時，VBR 能用最小體積保留最佳畫質。
影片上架與內容分發：YouTube、Vimeo 等平台的上傳檔案，通常建議使用高品質 VBR 編碼。
目標大小壓縮（Target File Size Encoding）：任何需要「精準控制輸出檔案體積」的業務場景，例如電子郵件附件、即時通訊傳檔、網頁嵌入影片。

CBR vs VBR 技術比較總表

技術項目	CBR（固定位元速率）	VBR（動態位元速率）
核心邏輯	每秒固定資料量	依場景複雜度動態分配
檔案大小預測	極高（幾乎精準）	單遍次較差，2-Pass 可精準控制
畫質表現	動態場景易出現壓縮瑕疵	整體畫質更均勻、細節保留更佳
編碼速度	快（單遍次即完成）	2-Pass 需兩倍掃描時間
適用場景	Livestreaming、Broadcasting、視訊會議	檔案儲存、VOD、目標大小壓縮
位元浪費	靜態場景浪費嚴重	幾乎無浪費，資料分配效率高
緩衝區需求	低且穩定	需較大緩衝區應對位元流波動

為什麼 Target File Size 需要精密的 Rate Control？

在工程實務上，「把影片壓小」從來不是單純的「調低解析度」或「砍半位元速率」就能解決的問題。當使用者要求一個精確的目標檔案大小（例如 8MB、25MB、或 100MB），編碼器面臨的是一個**受限最佳化（Constrained Optimization）**數學問題：

> 在總位元預算 B 的限制下，最小化整段影片的失真函數 D（Distortion）。

這需要 Rate Control 模組具備以下能力：

全域預算規劃：不能只看當前影格，必須預留位元給後續的複雜場景。
感知品質建模（Perceptual Quality Modeling）：人眼對暗部雜訊與亮部色偏的敏感度不同，編碼器必須把位元投資在「人眼最在意的地方」。
緩衝區約束遵守：確保位元流不會觸及解碼器的 VBV 上限，避免播放時出現卡頓。

Squishyfile 選擇在瀏覽器端透過 WASM（WebAssembly） 執行這整套邏輯，而非上傳到伺服器處理。這意味著我們的 2-Pass VBR 演算法必須在客戶端的記憶體與 CPU 限制內完成複雜的速率控制計算——這是一項極具挑戰性的工程實作，也是我們持續優化編碼器參數與記憶體管理策略的原因。

總結

CBR 與 VBR 並非絕對的優劣之分，而是設計目標的權衡（Trade-off）：

如果你需要穩定的網路傳輸與可預測的串流頻寬，CBR 是合理的選擇。
如果你追求極致的編碼效率，希望在特定檔案大小內榨出最佳畫質，2-Pass VBR 才是專業級的解答。

對於需要「自訂檔案大小（Custom Size）」的影片壓縮場景——例如將影片壓到 Email 附件上限、或符合社群平台的檔案規範——2-Pass VBR 的精準位元預算分配是唯一能在「體積限制」與「視覺品質」之間取得最佳平衡的技術路徑。

在 Squishyfile，我們把這套通常只出現在專業剪輯軟體（如 Premiere、HandBrake）中的編碼邏輯，透過 WASM 技術移植到瀏覽器內，讓你在不上傳檔案到伺服器的前提下，完成專業級的目標大小影片壓縮。

如果你對影片編碼的底層原理感興趣，或正在尋找一個安全、高效且支援精準檔案大小控制的線上影片壓縮工具，歡迎體驗 Squishyfile 的實際效果。

本文為 Squishyfile 技術團隊撰寫，內容基於 FFmpeg libx264/libx265 編碼器實作與影片壓縮工程經驗。