我的知識庫

整條管線與關鍵名詞：bitrate、resolution、fps、GOP、latency 到底在管什麼

閱讀時間約 13 分鐘

直播只有五個環節：擷取 → 編碼 → 傳輸 → 分發 → 播放。每一個環節都會加上延遲、都會改變畫質、都有一組可調參數，而這些參數彼此耦合——調高 fps 會吃掉 bitrate 的預算、縮短 GOP 會增加碼率、降低延遲會削弱抗抖動能力。把這五段畫成一張圖並標上各自的延遲貢獻，是之後所有決策的基礎。

📖 學

一、五段管線與各自在做什麼

[擷取]      攝影機 / 螢幕 / 音訊介面
   │        產出未壓縮或輕壓縮的原始影音
   ▼
[編碼]      H.264 / H.265 / AV1 編碼器
   │        把 1.5 Gbps 的原始訊號壓成 3 Mbps
   ▼
[傳輸]      RTMP / SRT / WebRTC（第一哩路：現場 → 雲端）
   │        跨公網，要處理丟包、抖動、重傳
   ▼
[分發]      轉碼 → 打包 → CDN / 媒體邊緣（最後一哩：雲端 → 觀眾）
   │        一變多：多碼率、多協定、多地區
   ▼
[播放]      播放器：下載 → 緩衝 → 解碼 → 顯示

一個未壓縮的 1080p60 訊號大約是 1920 × 1080 × 3 bytes × 60 ≈ 373 MB/s，約 2.99 Gbps。 壓成 6 Mbps 等於壓縮約 500 倍。整條管線的大部分複雜度，都來自這個壓縮動作帶來的後果：壓縮引入時間相依（這一幀依賴前一幀）、引入延遲（要先看到未來幾幀才能決定怎麼壓）、也引入脆弱性（丟一個封包可能毀掉接下來一整段）。

第一哩路與最後一哩路的需求完全相反，這是最常被混淆的一點。 第一哩路是「一條流、要絕對可靠、頻寬可控」，所以適合 ARQ 重傳型協定（SRT／RIST）；最後一哩路是「一變成百萬條、要能快取、要適應各種爛網路」，所以適合 HTTP 分片型協定（HLS／DASH）。拿 HLS 做現場回傳，或拿 SRT 推給一百萬觀眾，都是把工具用在錯的那一段。

二、Bitrate（位元率）：唯一真正決定畫質的數字

Bitrate 是每秒用多少位元描述影像，單位 bps。它是畫質的總預算，其他所有參數都是在決定這個預算怎麼花。

一個有用的歸一化指標是 bits per pixel per frame（bpp）：

bpp = bitrate ÷ (width × height × fps)

1080p30 配 4 Mbps：4,000,000 ÷ (1920 × 1080 × 30) = 0.0643 bpp 1080p60 配 4 Mbps：4,000,000 ÷ (1920 × 1080 × 60) = 0.0322 bpp

同樣 4 Mbps，把 fps 從 30 提到 60，每個像素可用的位元直接腰斬。 這就是為什麼「開 60fps 之後畫面變糊」——你沒有增加預算卻增加了要描述的東西。實務經驗值是 H.264 在 0.08–0.12 bpp 左右開始「看起來沒有明顯壓縮痕跡」，但這高度依賴內容複雜度，靜態講座遠低於此也沒問題，高速運動則遠高於此仍會崩。

三、Resolution（解析度）與 fps：兩種不同的「資訊量」

解析度決定空間細節，fps 決定時間細節。兩者都乘進同一個 bpp 分母，所以它們在搶同一筆預算。

決策方向很清楚：內容的運動量決定你該往哪邊花錢。

  • 棋牌、講座、新聞播報：運動少，空間細節重要 → 高解析度、低 fps（1080p30 甚至 25）
  • 體育、遊戲、賽車：運動多，時間連續性重要 → 可以降解析度換 fps（720p60 常優於 1080p30）

一個常見且昂貴的錯誤是「全部都開到最高」。4K60 的原始資訊量是 1080p30 的 8 倍，若 bitrate 沒有跟著乘上去，結果比 1080p30 更糟。

四、Keyframe／GOP：延遲、可切換性與碼率的三方取捨

編碼器產出三種幀：

幀型全名依賴大小（相對）
I 幀Intra-coded，也稱 keyframe不依賴任何其他幀最大，約 P 幀的 5–10 倍
P 幀Predicted依賴前面的幀中
B 幀Bi-directional predicted依賴前面與後面的幀最小

GOP（Group of Pictures） 是兩個 I 幀之間的距離。GOP = 2 秒、60fps，就是每 120 幀放一個 I 幀。

這個數字同時控制三件事：

切入點。 播放器只能從 I 幀開始解碼，所以 GOP 長度就是新觀眾最壞情況的等待時間，也是 ABR 切換碼率的最小粒度。

分片長度的下限。 HLS／DASH 的每個分片必須以 I 幀開頭，所以分片長度必須是 GOP 的整數倍。想要 2 秒分片就必須有 ≤2 秒的 GOP。

碼率效率。 I 幀貴。GOP 從 4 秒縮到 1 秒，I 幀密度變 4 倍，相同畫質下碼率上升（典型增幅在 10–20% 量級，依內容而定）。

B 幀是低延遲的敵人。 因為 B 幀依賴「後面的幀」，編碼器必須先緩衝未來幾幀才能編出它，這直接加上延遲。所有低延遲設定的第一條都是關掉 B 幀（x264 的 bframes=0，或用 baseline／main profile 的受限配置）。

五、Latency（延遲）：它是一個預算，不是一個開關

「延遲」這個詞至少有三種用法，混用會導致完全談不攏：

Glass-to-glass（端到端）——鏡頭前發生的事，到觀眾螢幕上顯示出來，中間經過的總時間。這是唯一對使用者有意義的定義。

協定延遲——某個協定本身結構上引入的延遲（例如 HLS 分片長度 × 緩衝分片數）。供應商報的數字通常是這個，它比 glass-to-glass 小。

網路延遲（RTT）——純粹的來回傳輸時間。它只是上面那些的一個組成部分。

把 glass-to-glass 拆開，典型的分配是：

環節典型貢獻可壓縮性
擷取與前處理20–60 ms低（硬體決定）
編碼（含 lookahead／B 幀）50–300 ms高（關 B 幀、降 lookahead、調 preset）
第一哩路傳輸50–200 ms中（看距離與協定的重傳策略）
轉碼與打包100 ms – 數秒高（分片長度主導）
CDN 分發20–100 ms低—中
播放器緩衝500 ms – 30 s最高——這通常是最大的一塊
解碼與顯示20–50 ms低

播放器緩衝幾乎總是最大的一項，也是最容易被忽略的一項。 一個設了 3 個分片緩衝、分片 6 秒的 HLS 播放器，光是緩衝就有 18 秒。你把編碼延遲從 200 ms 優化到 100 ms，對使用者完全沒有感覺。延遲優化必須從最大的那一塊開始，詳見 分發與延遲。

延遲與穩定性是直接對立的。 緩衝的存在就是為了吸收網路抖動；緩衝越小，一個遲到的封包就越可能造成卡頓。所以「延遲要多低」的正確問法是「這個場景能忍受多少卡頓率」，而不是「越低越好」。

六、ABR：為什麼要同一個內容編好幾份

觀眾的網路條件差異巨大（從 50 Mbps 光纖到 1 Mbps 的行動網路）。ABR（Adaptive Bitrate，自適應位元率） 的做法是把同一個內容編成數個不同碼率的版本（稱為 ladder，階梯），播放器根據當下的下載速度逐片選擇要拉哪一階。

這帶來一個結構性後果：ABR 需要分片，分片需要 HTTP，HTTP 需要緩衝——所以 ABR 與極低延遲在架構上互相拉扯。WebRTC 走的是另一條路：不切片，改用即時的碼率調適（編碼器直接根據回饋降碼率），代價是失去 HTTP CDN 的快取紅利。詳見 傳輸協定。

七、把名詞接回場景

場景延遲要求典型選擇
新聞直播、演唱會轉播10–30 秒可接受HLS/DASH，長分片，大緩衝，最省錢
體育賽事2–6 秒（要贏過電視）LL-HLS／LL-DASH
線上拍賣、互動問答1–3 秒LL-HLS 調校，或 WebRTC
真人荷官、雲端遊戲、視訊會議< 500 msWebRTC

延遲要求往下一階，成本與複雜度就往上一階，而且不是線性的。這是整個專欄反覆出現的主線。

🧠 記

bpp 是畫質的真實指標，不是 bitrate 單獨的數字；fps 加倍等於 bpp 腰斬。

GOP 同時決定切入延遲、分片長度下限與碼率效率，三者互相牽制。

B 幀是低延遲的敵人，低延遲設定一律先關掉它。

延遲是預算不是開關，而播放器緩衝通常佔最大一塊——優化要從最大的那塊開始。

第一哩路與最後一哩路需求相反：前者要可靠（ARQ），後者要可快取（HTTP）。

✍️ 實踐

花 20 分鐘做一次延遲歸因，不需要任何付費服務：

  1. 用 OBS 推一條流到任一平台，開 1080p30、4 Mbps、GOP 2 秒。
  2. 把手機碼表（毫秒級）對著鏡頭拍，同時在另一個螢幕開播放頁面。
  3. 同時截圖兩個畫面，相減得到 glass-to-glass 延遲。
  4. 接著只改一項、各測一次：GOP 改 1 秒 → 分片改短 → 播放器緩衝改小。記錄每一項各自省下多少毫秒。

做完這一輪你會得到自己管線的延遲分配表，而那張表會告訴你後面該往哪裡花力氣——幾乎所有人做完都會發現答案跟自己原本以為的不一樣。

🔗 延伸學習

相關

反向連結