空間壓縮與時間壓縮：影片編碼器的核心理論

為什麼一部未壓縮的 1080p60 影片每秒會吃掉數百 MB 的頻寬？為什麼 H.264、HEVC、AV1 這些 Codec 能將檔案縮小到千分之一，卻仍保持肉眼難以察覺的畫質差異？

身為長期耕耘瀏覽器端 WASM 影片壓縮技術的開發者，我經常被問到：「你們的壓縮工具是怎麼在本地端做到檔案縮小的？」答案不在於某個神奇的參數，而在於理解 Spatial Compression（空間壓縮） 與 Temporal Compression（時間壓縮） 這兩個編碼器最核心的數學基礎。

這篇文章不談操作教學，而是從訊號處理與資訊理論的角度，拆解現代 Video Codec 的運作原理。無論你是前端工程師、內容創作者，或是對 how video codec works 有興趣的技術愛好者，理解這些底層機制，將幫助你在選擇編碼標準時做出真正專業的判斷。

為什麼原始影片資料量會大到離譜？

在談壓縮之前，我們先用一條簡單的算式理解問題的嚴重性。

未壓縮 1080p60 影片的資料量試算

一張 Full HD（1920×1080）的影像，每個像素以 8-bit RGB（3 個通道）儲存：

單張影像大小 = 1920 × 1080 × 3 bytes ≈ 5.93 MB

若影片以 60fps 播放，每秒的資料量：

每秒資料量 = 5.93 MB × 60 = 355.8 MB/s

一部 10 分鐘（600 秒）的未壓縮影片：

總容量 = 355.8 MB/s × 600 s ≈ 213 GB

換句話說，如果你要在 YouTube 上看一部 10 分鐘的 1080p 影片，未壓縮的情況下需要下載 超過 200 GB。這還沒算 4K（約 4 倍）或 8K（約 16 倍）的場景。

這正是 Video Compression Algorithms 存在的根本原因：透過數學方法，移除視覺上冗餘的資訊，將 213 GB 壓到 100 MB 甚至更小，同時維持可接受的 畫質（Perceptual Quality）。

空間壓縮（Spatial Compression / Intra-frame）

空間壓縮處理的是「單一張畫面內部」的冗餘資訊。它的哲學很簡單：人眼對影像的感知並非均勻的，某些顏色與亮度的細節我們根本看不見。

從 JPEG 到影片：相同的數學基礎

如果你理解 JPEG 的壓縮原理，你就已經掌握了空間壓縮的一半。H.264、HEVC、AV1 的 Intra-frame 編碼，本質上都是將畫面切割後，對每個區塊進行類似的頻域轉換。

Macroblock：畫面的基本處理單位

早期的編碼器（如 H.264）將畫面切割為 16×16 像素的 Macroblock（大區塊）。HEVC 則進化為更彈性的 Coding Tree Unit（CTU），最大可達 64×64，能根據畫面複雜度動態調整區塊大小。

每個區塊會經歷以下處理流程：

色彩空間轉換：從 RGB 轉為 YCbCr（亮度/藍色色度/紅色色度）
Chroma Subsampling（色度採樣縮減）：利用人眼對亮度（Y）敏感、對色度（Cb/Cr）遲鈍的特性，減少色度資訊的取樣率。常見的 4:2:0 格式，色度解析度只剩下亮度的一半，資料量直接減少約 50%。
Discrete Cosine Transform（DCT，離散餘弦轉換）：將空間域（像素值）轉換為頻率域（餘弦波係數）。

DCT：為什麼它這麼重要？

DCT 是整個空間壓縮的靈魂。一個 8×8 的像素區塊，經過 DCT 後，會被拆解成 64 個不同頻率的餘弦波係數。

低頻係數：代表大塊的顏色變化（人眼最敏感）。
高頻係數：代表細微的紋理與邊緣（人眼較不敏感）。

編碼器接下來會進行 Quantization（量化）：將高頻係數除以較大的量化值，讓許多細微係數變成零。最後透過 Run-length Encoding + Huffman Coding，把這些稀疏的矩陣壓縮成極小的位元流。

這就是為什麼過度壓縮的影片會出現 Block Artifact（區塊效應）：當量化過度激進，高頻資訊被完全抹除，邊緣就會變得模糊或出現馬賽克。

時間壓縮（Temporal Compression / Inter-frame）

如果空間壓縮處理的是「一張照片怎麼變小」，那時間壓縮處理的就是「影片的下一幀跟上一幀有多像」。這是影片能壓縮到千分之一的關鍵。

I-frame、P-frame、B-frame：三種幀的階級制度

現代 Codec 不會對每一幀都進行完整的空間壓縮。相反地，它將畫面分為三種類型：

I-frame（Intra-coded Frame，關鍵幀）

完整獨立的畫面，僅使用空間壓縮（Intra-frame）。
相當於影片中的「參考基準點」，可以獨立解碼。
檔案體積最大，但解碼最快。

P-frame（Predicted Frame，預測幀）

不儲存完整畫面，只記錄「與前一個 I-frame 或 P-frame 的差異」。
透過 Motion Estimation（動態估計），找出畫面中物體的移動向量（Motion Vector）。
檔案體積遠小於 I-frame。

B-frame（Bidirectional Predicted Frame，雙向預測幀）

最高效的幀類型。同時參考「前一幀」與「後一幀」進行預測。
記錄的是「過去與未來之間的差異」，因此能達到最高的壓縮率。
代價是編碼與解碼的延遲較高，因為需要緩衝未來的幀。

一個典型的 GOP（Group of Pictures） 結構可能長這樣：

I B B P B B P B B I ...

在這個結構中，只有 I-frame 是完整的，其餘都依賴時間壓縮來重建。

Motion Estimation：時間壓縮的引擎

這是時間壓縮中最消耗運算資源的步驟。編碼器會在參考幀中搜尋每個 Macroblock 的最佳匹配位置，計算出 Motion Vector（動態向量）。

舉例來說，如果畫面中有一輛車從左向右移動：

不儲存「車子在每一幀的完整像素」。
只儲存「車子的區塊向右移動了 23 個像素」這個向量。
解碼時，從參考幀複製該區塊，再根據向量位移，最後加上殘差（Residual）修正細節。

HEVC 相較於 H.264，在 Motion Estimation 上做了重大改進：支援更細的 1/4 像素甚至 1/8 像素精度的動態向量，並使用更高效的預測演算法，因此能在相同畫質下減少約 50% 的位元率。

空間壓縮與時間壓縮的協作關係

單獨看空間壓縮，只能將影像壓到原本的 1/10 到 1/20。單獨看時間壓縮，沒有參考幀也無從發揮。真正的威力來自兩者的結合：

壓縮類型	處理對象	核心技術	壓縮貢獻
空間壓縮（Intra-frame）	單一畫面內部	DCT、量化、Chroma Subsampling	約 10~20 倍
時間壓縮（Inter-frame）	幀與幀之間	Motion Estimation、I/P/B-frame	約 50~100 倍
兩者結合	完整影片流	GOP 結構、Entropy Coding	總計 100~1000 倍

這就是為什麼 H.264 能將 213 GB 的原始影片壓到 200 MB 左右，而 HEVC 與 AV1 透過更精進的區塊分割、更智慧的預測模式，能進一步壓到 100 MB 以下。

理解 Codec 本質，才能選對工具

身為開發者，我認為理解這些底層原理不僅是學術興趣，更是實務上的必要。

當你知道 Temporal Compression 依賴 Motion Estimation，你就會明白為什麼「畫面劇烈變化的影片」（例如快速切換的 MV、煙火爆炸場景）壓縮率會遠低於「靜態對話場景」。因為劇烈變化意味著殘差變大，P-frame 與 B-frame 的優勢被削弱。

當你知道 DCT 與 Quantization 會抹除高頻細節，你就會理解為什麼文字、線條、UI 介面在過度壓縮後會變得模糊——這些元素正好充滿高頻資訊。

這也是我們在開發 Squishyfile 時堅持瀏覽器端 WASM 本地壓縮的原因之一：影片編碼涉及大量敏感的像素級運算，將檔案留在使用者本地端處理，不僅保護隱私，也讓開發者能更精細地控制 Spatial 與 Temporal 的壓縮參數，而不受伺服器端黑箱演算法的限制。

總結

Video Compression Algorithms 的本質，是一場針對人眼感知極限的數學優化：

空間壓縮利用 DCT 與 Chroma Subsampling，移除單一畫面中人眼不易察覺的細節。
時間壓縮利用 I-frame、P-frame、B-frame 與 Motion Estimation，移除幀與幀之間的重複資訊。
兩者結合，才讓現代串流媒體與線上影片成為可能。

無論你正在評估 H.264 vs HEVC 的專案選型，或是單純想理解手邊影片檔案為什麼能這麼小，掌握 Spatial Compression 與 Temporal Compression 的運作邏輯，都是建立技術判斷力的重要基石。

希望這篇文章能為你的技術決策提供紮實的理論後盾。如果你對瀏覽器端影片處理或自訂壓縮參數有進一步的興趣，歡迎持續關注我們的技術分享。