編碼是整條管線裡唯一「資訊被永久丟棄」的環節。傳輸可以重傳、分發可以快取、播放可以緩衝，但編碼器丟掉的細節永遠回不來。因此編碼參數的選擇，決定了後面所有環節的畫質上限——後面再怎麼優化，也只能逼近編碼當下的品質，不可能超過它。
📖 學
一、編碼器選擇：三代 codec 的實際取捨
| Codec | 標準化 | 相對 H.264 的碼率節省 | 授權 | 硬體解碼普及度 | 即時編碼成本 |
|---|---|---|---|---|---|
| H.264 / AVC | 2003 | 基準 | 有專利池，實務上已廣泛授權 | 幾乎 100% | 低 |
| H.265 / HEVC | 2013 | 約 25–50%（依內容與設定） | 專利池分裂，授權複雜 | 高（但瀏覽器端受限） | 中 |
| AV1 | 2018 | 相對 H.264 約 30–50% | 免權利金 | 2026 年已廣泛（新手機／瀏覽器／電視） | 高 |
三件實務上比壓縮率更重要的事：
H.265 的問題從來不是技術，是授權與瀏覽器。 它的壓縮效率沒有爭議，但專利池分裂（HEVC Advance、Access Advance、Velos Media 等）讓授權成本難以預估，而瀏覽器端的支援長期落後——這使它在「要能在網頁上播」的場景裡一直不是預設答案，在封閉生態（機上盒、App、廣電）裡則很常見。
AV1 的瓶頸在編碼端不在解碼端。 到 2026 年解碼側已經不是問題（新裝置普遍有硬體解碼），但即時編碼仍然貴。SVT-AV1 在高 preset（速度快、壓縮差）才跑得到即時 1080p，而低 preset 的壓縮優勢需要更多算力並額外增加延遲。這使 AV1 在點播（可以離線慢慢編）的經濟性遠優於直播。把點播的 AV1 節省數字直接套到直播預算上，是一個常見的高估。
對直播而言，H.264 在 2026 年仍然是最安全的預設，理由不是它最好，而是它在「任何裝置都能解、編碼成本最低、延遲最可控」三項上同時及格。升級的正確觸發條件是出流成本已經大到足以攤銷編碼成本——這通常發生在規模化之後，見 成本模型。
二、硬體編碼 vs 軟體編碼
軟體編碼（x264、x265、SVT-AV1，跑在 CPU 上）：同碼率下畫質較好，參數可調性極高，但吃 CPU、密度低。
硬體編碼（NVENC、Quick Sync、AMF、Apple VideoToolbox）：固定功能電路，速度極快、幾乎不吃 CPU、密度高，但同碼率下畫質通常略遜於軟體編碼的慢速 preset，可調參數少。
判斷方式很直接：
單機推流（個人直播主）→ 用硬體編碼。 你的 CPU 要同時跑遊戲／OBS／瀏覽器，把編碼丟給 GPU 是正確的資源配置。畫質差距在 6 Mbps 這種相對寬裕的碼率下很難察覺。
雲端轉碼（一變多）→ 看密度與成本。 要把一條源流轉成五個碼率再乘以上千路，硬體編碼的密度優勢直接變成錢。但碼率壓得很低時（例如 ABR 階梯的最底階 400 kbps），軟體編碼的品質優勢會變得明顯。
延遲敏感 → 硬體編碼通常更可預測。 固定功能電路的編碼時間變異小，軟體編碼在複雜場景可能突然變慢。
三、CBR vs VBR：直播幾乎一律 CBR
| 模式 | 行為 | 適用 |
|---|---|---|
| CBR（固定位元率） | 不論內容複雜度，碼率維持恆定 | 直播：下游頻寬可預測，不會突發爆量 |
| VBR（可變位元率） | 複雜段落多給、簡單段落少給 | 點播：同樣檔案大小下畫質更好 |
| CRF／CQ（固定品質） | 固定品質，碼率完全隨內容浮動 | 封存、編輯母帶 |
直播用 CBR 的理由不是畫質，是可預測性。 傳輸鏈路、CDN 計費、播放器的 ABR 判斷，全部建立在「這一階大約就是這個碼率」的假設上。如果碼率會突然從 3 Mbps 跳到 12 Mbps，播放器的頻寬估計會失準、觀眾會卡、CDN 帳單會失控。
實務上常用的是 capped VBR（上限受限的 VBR）：允許小幅浮動以在簡單畫面省頻寬，但設一個硬上限（例如目標 4 Mbps、上限 5 Mbps）。這是個折衷，但要確認下游每一環都接受這個上限。
VBV／HRD buffer 是 CBR 真正的控制旋鈕。 設定 vbv-maxrate 與 vbv-bufsize 決定編碼器允許多大的瞬時偏離。vbv-bufsize 設成與 maxrate 相同（即 1 秒緩衝）會讓碼率非常平穩但畫質在複雜場景下掉得明顯；設成 2 秒則比較寬鬆。低延遲場景應該用較小的 VBV buffer，因為大 buffer 本身就是延遲。
四、低延遲的編碼設定
把編碼延遲壓到最低的設定組合，每一條都有明確代價：
| 設定 | 作用 | 代價 |
|---|---|---|
bframes=0 | 消除「等未來幀」的延遲 | 碼率效率下降約 10% 量級 |
lookahead 調小或關閉 | 編碼器不預看後續內容 | 碼率分配變差 |
preset 調快 | 減少編碼計算時間 | 同碼率畫質下降 |
tune=zerolatency | x264 的組合開關，一次設好上述 | 同上綜合 |
| GOP 縮短 | 縮短切入延遲 | I 幀變密，碼率上升 |
slice-max-size / 分片編碼 | 可以邊編邊送，不必等整幀 | 實作複雜度 |
| VBV buffer 縮小 | 減少編碼器端緩衝 | 複雜場景畫質波動變大 |
這些設定合計可以把編碼延遲從 300 ms 級壓到 50 ms 級，但如果你的播放器緩衝是 10 秒，這整件事對使用者毫無意義。先量測延遲分配再決定要不要做這些。
五、音訊：被忽略但最容易毀掉體驗的一環
觀眾對音訊問題的容忍度遠低於畫面問題。畫面糊一下可以接受，聲音破一下就會關掉。
實務要點：
編碼器幾乎一律 AAC-LC（相容性最佳），碼率 128 kbps 立體聲對多數內容足夠，語音為主可以降到 64–96 kbps。Opus 在 WebRTC 場景是預設且表現更好，但在 HLS／RTMP 生態相容性較差。
取樣率用 48 kHz。 44.1 kHz 是 CD 遺產，在影音鏈路裡會引入不必要的重取樣。
音訊延遲必須與影像對齊。 音訊處理鏈（壓縮器、等化器、降噪）會引入延遲而影像鏈不會，造成唇音不同步。OBS 有「音訊同步偏移」可以逐軌補償，正確做法是量測而不是憑感覺調。
響度要正規化。 直播平台多半會做響度正規化，推流端做得太大聲只會被壓回去並損失動態。目標落在 −16 到 −14 LUFS 是常見實務。音訊鏈的推理在 Hi-Fi 音響知識 有更完整的展開。
六、OBS 的場景、來源與多軌
OBS 的核心抽象只有三層：來源（source）→ 場景（scene）→ 輸出（output）。
場景切換是直播最基本的製作動作，而它有一個常被忽略的成本：切換場景若涉及解析度或來源變化，編碼器可能被迫產生一個 I 幀，造成瞬間碼率尖峰。密集切換的節目要注意這點。
多音軌（multi-track） 讓你把「給觀眾聽的混音」與「給錄影存檔的分軌」分開——例如軌道 1 是最終混音推流，軌道 2–6 分別是麥克風、遊戲、音樂、來賓，錄影時全部保留，事後可以重新混音。這是直播與錄影需求衝突時的標準解法，值得在一開始就設好。
OBS 支援 SRT 與 RIST 輸出（不只 RTMP），這在跨公網推流時是重要能力，見 傳輸協定。
🧠 記
編碼是唯一不可逆的環節，後面所有優化都只能逼近它的品質上限。
H.264 在 2026 年對直播仍是最安全的預設；AV1 的瓶頸在即時編碼成本，點播的節省數字不能直接套用。
直播用 CBR 是為了可預測性，不是畫質。 VBV buffer 是真正的控制旋鈕。
低延遲編碼設定的第一條永遠是關掉 B 幀；但做之前先確認編碼不是延遲的主要來源。
音訊問題的容忍度遠低於畫面問題，而音訊延遲補償要用量的不要用猜的。
✍️ 實踐
用同一段素材做一次 bpp 對照，30 分鐘：
- 錄一段 60 秒、有明顯運動的畫面（走動、手勢、捲動畫面皆可）。
- 用同一個編碼器，固定 1080p，分別編出：30fps/4Mbps、60fps/4Mbps、60fps/8Mbps。
- 逐段比較，特別看運動最劇烈的那兩秒。
- 算出三者的 bpp，確認你看到的差異與 bpp 排序一致。
這個練習的目的是建立「bpp 而非 bitrate」的直覺。做完之後你在面對「要不要開 60fps」這種問題時，會自動先問「預算有沒有跟著加」。
🔗 延伸學習
- OBS Project — Streaming With SRT or RIST Protocols——官方 wiki，說明 OBS 如何設定這兩個協定的 URL 與模式，是把 OBS 從 RTMP 推進到現代傳輸協定的最短路徑。
- Fora Soft — AV1 Encoding in 2026: When It Cuts Your CDN Bill——把 AV1 的決策條件放在「出流成本 vs 編碼成本」的框架上討論；數字來自該站自己的基準測試，應視為供應商級證據。
相關
- 直播視頻研究——由淺入深，最後到安全（hub）
- 整條管線與關鍵名詞
- 轉碼與多位元率
- DaVinci Resolve 研習 — 檔案交付側的 codec 與碼率決策