硬體影像編碼器比較：NVENC vs AMF vs QuickSync vs Apple VideoToolbox。

四家廠商，四塊固定功能的矽晶片，一項工作 — 在五毫秒內把一格畫面的像素變成幾 KB 的 H.265 或 AV1，每秒六十次，而且不漏掉任何一格。以下說明 NVIDIA、AMD、Intel 與 Apple 在低延遲串流上實際如何比較，以及 Remio 如何在執行階段選出最合適的那一個。

為什麼硬體編碼器對遠端桌面很重要

在快速的 CPU 核心上用 libx264 編碼一格 1080p 畫面。在現代的 Apple M 系列或 Ryzen 7000 上，ultrafast 預設大約能做到 8 到 12 毫秒，任何想保留畫質的設定則更久。這聽起來還可以忍受，直到你想起預算：60 FPS 下每格只有 16.6 毫秒。再加上擷取、封包化、pacer 排隊、網路送出、解碼與渲染。CPU 編碼不只會拖慢你 — 它會吃光整個延遲預算，超過 1080p60 就會掉格。

硬體編碼器的解法，是把固定功能的矽晶片專門用來做同一件事。NVIDIA 稱它的區塊為 NVENC。AMD 稱為 AMF（更精確地說，是 AMF 所驅動的 VCN 引擎）。Intel 稱為 QuickSync（其內顯中的媒體引擎）。Apple 稱為 VideoToolbox（這是 API；矽晶片則是 M 系列與 A 系列晶片上的媒體引擎）。四者存在的理由只有一個：軟體編碼無法達到現代螢幕、現代 GPU 與現代使用者所期待的延遲與畫面更新率目標。

對 Remio 來說，在編碼器省下的每一毫秒，都是使用者在 pacer、網路與渲染器那端拿回來的一毫秒。我們公布的延遲預算目標為區域網路上約 8 毫秒的處理時間（其餘是你的螢幕本身 60 Hz 的更新節奏） — 編碼時間是其中最大的單一變數。編碼器的選擇與設定，決定了下游的一切。

四家廠商一覽

在深入各家之前，先弄清楚我們到底在比較什麼會有幫助。它們不是可以互換的函式庫 — 它們是晶片上的實體區塊，各有自己的指令集、驅動程式堆疊、怪癖與多年的發展藍圖。它們在支援的編解碼器、產生的畫質、達到的延遲、耗電量，以及存在於哪些平台上，都不相同。

• NVENC 自 2012 年（Kepler）起搭載於每一張 NVIDIA GeForce、Quadro 與 RTX 上。世代與架構系列綁定：第 1 代在 Kepler，第 8 代在 Ada Lovelace。Hopper 資料中心產品則有不同的節奏。
• AMF 對外開放 AMD 的 VCN（Video Core Next）引擎，它取代了較舊的 VCE。適用於每一張 Vega、RDNA、RDNA2 與 RDNA3 GPU，以及較新的 APU。
• QuickSync 自 2011 年的 Sandy Bridge 起就內建於 Intel 內顯 — 使其成為全球部署最廣的硬體編碼器。Arc 獨立顯示卡使用相同的架構，並放大規模。
• VideoToolbox 是 Apple 的 API；底層的矽晶片是媒體引擎，內建於每一台 Apple 晶片 Mac、每一支自 A6 以來的 iPhone，以及每一台 iPad。M 系列晶片依型號搭載一到兩個引擎。

NVENC — NVIDIA 八代的精進

NVENC 是多數串流軟體拿來當基準測試對象的編碼器，一部分是因為 NVIDIA 有行銷預算，一部分是因為這塊矽晶片十年來確實非常出色。這個區塊已歷經八個世代：

• 第 1–3 代（Kepler 到 Maxwell，2012–2014）— 僅支援 H.264，可用於串流，但畫質明顯落後 libx264。
• 第 4 代（Pascal，GTX 10 系列）— 加入 H.265 編碼。這是 NVENC 畫質在相同位元率下追上、甚至可說超越 libx264 fast 預設的世代。
• 第 6 代（Turing，RTX 20 系列、GTX 16 系列）— 常被提及的「Turing NVENC」大躍進。低位元率下的畫質進步到讓實況主不再假裝 CPU 編碼對直播情境有明顯優勢。
• 第 7 代（Ampere，RTX 30 系列）— 微幅精進，每瓦畫質大致與 Turing 相當。
• 第 8 代（Ada Lovelace，RTX 40 系列）— NVIDIA 第一個具備硬體 AV1 編碼的世代，高階型號還配有雙編碼器引擎。Ada NVENC 能以 CPU 成本的一小部分，做出與 libaom-av1 medium 預設相當的 AV1 畫質。

在低延遲用途上，NVENC 提供三種相關的位元率控制模式。以 CBR 搭配 low-latency 調校與 p1 預設（最快）是標準設定：輸出位元率確定、單格前瞻、沒有 B 格。Remio 在 Windows 上執行 hevc_nvenc 時，使用的正是這組設定。Ada Lovelace 在 1080p60 H.265 的編碼時間一貫為 1 到 3 毫秒。

一個歷史遺留的坑：消費級 NVENC 多年來被 NVIDIA 的驅動程式限制為三個同時編碼連線。這個限制在 2023 年放寬到八個，之後實質上已取消。如果你讀到的是過時的論壇討論串在警告這件事，這個警告已經不適用了。

AMF — AMD 這位終於迎頭趕上的後進者

AMD 的 AMF（Advanced Media Framework）是 API；底層引擎則經歷了兩種截然不同的架構。較舊的 VCE（Video Coding Engine）自 2012 年的 GCN 世代顯示卡開始搭載，在編碼器正面比較中長期是弱項 — 在相同位元率下畫質明顯不如 NVENC，尤其是在動態較多的內容上。AMD 知道，串流社群知道，基準測試也證實了這一點。

這個局面隨著 VCN（Video Core Next）改變，它在 Vega 上推出，並在之後每一代持續精進：

• VCN 1.0–2.0（Vega、RDNA1）— H.264 與 H.265，畫質終於逼近 NVENC Pascal/Turing，只差一絲之遙。
• VCN 3.0（RDNA2，RX 6000 系列）— 畫質大幅提升，尤其是在低位元率下。這是第一個我能放心推薦用於遊戲串流的 AMD 世代。
• VCN 4.0（RDNA3，RX 7000 系列）— 與 NVIDIA Ada 同步加入 AV1 編碼。高階型號有兩個編碼器可供平行連線。在第三方基準測試中，AV1 畫質與 NVIDIA 的 AV1 不相上下。

在低延遲串流上，AMF 提供 ultralowlatency 用途預設、speed 畫質預設，以及 cbr 位元率控制模式。Remio 使用 hevc_amf 並搭配三者 — 即我們串流架構筆記中記載的同一組預設三件組。RDNA3 在 1080p60 H.265 的編碼時間通常為 2 到 4 毫秒。RDNA2 約為 3 到 5 毫秒。較舊的 VCN 1.x 世代顯示卡則接近 5 到 7 毫秒 — 仍在預算之內，但對關鍵格（keyframe）尖峰的餘裕較少。

五年來，AMD 的編碼器一直是笑柄。RDNA2 修正了它。RDNA3 讓它在 AV1 上具備競爭力。串流編碼器的雙寡頭如今成了三強鼎立，這對每個人都是好事。

QuickSync — 默默無聞的普及冠軍

QuickSync 是你幾乎肯定已經擁有的編碼器。自 2011 年的 Sandy Bridge 起，每一顆具備內顯的 Intel CPU 都內建了它 — 這意味著十多年來的筆電、NUC 與辦公桌機，都有硬體影像編碼閒置著，只因為使用者以為自己需要獨立顯示卡。其實不需要。

這個架構隨著 Intel 內顯系列一同演進：

• Sandy Bridge 到 Skylake（2011–2015）— 僅支援 H.264，畫質普通，但延遲與耗電對筆電來說是同級最佳。
• Kaby Lake 到 Coffee Lake（2016–2018）— 加入 H.265、10 位元、4K 編碼。
• Ice Lake 之後（2019 起）— Gen11/Gen12 Xe 內顯大幅提升畫質。許多基準測試將 Gen12 QuickSync 評為與 NVENC Turing 只差幾個百分點。
• Arc 獨立顯示卡（2022 起）— Intel 的第一個獨立 GPU 系列。相同的 Xe-HPG 架構放大規模，並具備 AV1 編碼。Arc 是第一個推出硬體 AV1 的消費級 GPU — 比 NVIDIA Ada 與 AMD RDNA3 更早上市 — 畫質出乎意料地優秀。Intel Arc A380 在純 AV1 的每塊錢處理能力上，仍是荒謬的划算。

熱能表現是 QuickSync 安靜的超能力。因為它位於 SoC 上本來就存在的內顯中，使用它的邊際成本只有編碼區塊本身 — 不需要喚醒獨立顯示卡，也不需要啟動 GDDR6 記憶體控制器。在 ThinkPad 或 NUC 上，QuickSync 以大約四分之一的系統整體功耗，提供與 NVENC 相當的畫質。對 Remio 的 Windows 主機來說，QuickSync 是在 NVENC 與 AMF 之後的第三順位備援 — 不是因為它比較差，而是因為擁有獨立顯示卡的使用者通常希望把內顯留給其他工作。

VideoToolbox — Apple 晶片統一的媒體引擎

Apple 並不像 NVIDIA 那樣替自家的硬體編碼器行銷一個品牌名稱。API 是 VideoToolbox；矽晶片是媒體引擎（Media Engine），一個由 Apple 設計、內建於每一台 M 系列 Mac 與每一顆自 A6 起的 iPhone/iPad SoC 的區塊。

媒體引擎的數量依型號而異：

• M1、M2、M3 — 一個媒體引擎。
• M1 Pro/Max、M2 Pro/Max、M3 Pro/Max — 兩個媒體引擎。
• M1 Ultra、M2 Ultra — 四個媒體引擎（每個融合晶粒兩個）。
• M3 Max（16 核心 CPU） — 兩個媒體引擎。
• M4 系列 — 更新的媒體引擎，H.265 吞吐量更高。

每個媒體引擎都以硬體處理 H.264、H.265 與 ProRes 的編碼／解碼。ProRes 編碼是影片剪輯者最看重的功能 — 沒有其他消費級晶片具備 — 但對串流來說，相關的能力是高效率的 H.265 main10 編碼，以及低得驚人的編碼延遲。

一個值得注意的缺口：目前出貨的任何 Apple 晶片都沒有 AV1 編碼。M 系列晶片自 M3 起能解碼 AV1，但無法編碼。從 Mac 串流出去時，H.265 在可預見的未來仍是實際的預設選擇。

Apple 真正勝出的地方是能源效率。在 M2 Pro 上以 30 Mbps 編碼 4K60 H.265，整個媒體引擎大約耗電 3 到 5 瓦。在 RTX 4070 上執行同等的 NVENC 工作負載，系統整體耗電接近 35 瓦 — 其中大部分是獨立 GPU 的待機底線，而不是編碼區塊本身。對於 24 小時開機、等著用戶端連線的 Mac mini 主機來說，這就是「電費單上幾乎察覺不出來」與「確實感覺得到」之間的差別。

並排比較

以下用相同的維度比較這四種引擎。延遲數字為 1080p60 H.265 超低延遲預設、停用 B 格、單格 VBV — 即 Remio 的設定。畫質為在 8 Mbps CBR 下的感知粗略排名；絕對差異很小。

誠實的總結：在遠端桌面串流實際使用的設定下（CBR、低延遲、無 B 格），四者都夠好，而且餘裕很大。差異在於 AV1 支援（NVIDIA / AMD / Intel — 不包含 Apple）、能源效率（Apple 最佳，其次是 Intel 內顯，再其次是其他所有人），以及平台可用性（你無法在 Windows 主機上選擇 VideoToolbox，也無法在 Mac 上選擇 NVENC）。

Remio 在執行階段選擇什麼

Remio 在啟動時探測主機的能力，並依確定性的優先順序選出編碼器。Windows 主機與 Mac 主機遵循相同的選擇邏輯。

在 Windows 主機上：

1. NVENC（hevc_nvenc / h264_nvenc）— 當存在 NVIDIA GPU 且驅動程式有回應時優先選用。之所以偏好，是因為它在最廣泛的硬體世代上，都是延遲最一致偏低的編碼器。
2. AMF（hevc_amf / h264_amf）— 當存在具備 VCN 的 AMD 獨立顯示卡或 APU 時第二順位選用。設定為 usage=ultralowlatency、quality=speed、rc=cbr。
3. QuickSync（hevc_qsv / h264_qsv）— 當存在 Intel 內顯時第三順位選用。在我們的管線中功能上等同；如果有獨立顯示卡，我們傾向把內顯留給其他用途。
4. libx264 CPU 備援 — 僅在沒有任何硬體編碼器回應時才選用。上限為 720p60 或 1080p30，以維持在延遲預算之內。

在 Apple 主機上：VideoToolbox 是唯一的選項，也是我們唯一想要的。每一台受支援的 Mac（macOS 15+）內的媒體引擎，開箱即能處理 H.265 main10。不需要備援路徑。

編解碼器偏好是硬體 H.265 優先，H.264 作為通用備援 — 端對端、在每個平台皆然。Remio 目前不使用 AV1（為此所需的主機編碼、用戶端解碼與編解碼器協商都不在管線中）；即使在技術上能做 AV1 的硬體上，它仍堅持使用 H.265，因為在區域網路上，瓶頸是編碼延遲，而不是位元率。

畫質與延遲的取捨

每個硬體編碼器都提供同樣的幾個旋鈕，而每個旋鈕都以相同的方向，在畫質與延遲之間做取捨。Remio 的設定位於延遲旋鈕最激進的一端，因為遠端桌面就定義而言是即時的應用程式，一格超過 20 毫秒的舊畫面，比一格略比理想模糊的畫面更糟。

• CBR 與 VBR。可變位元率會把位元花在有幫助的地方，在相同平均位元率下產生較好的畫質。但 VBR 也會使每格的大小無法預測，進而使 pacer 排隊無法預測，使延遲無法預測。Remio 一律使用 CBR。畫質上的代價很小；延遲一致性的好處卻很大。
• B 格。B 格同時參考過去與未來的畫格，所以解碼器必須等到未來的畫格抵達才能解碼 B 格。這對隨選影片沒問題，對即時應用卻是致命的。Remio 在每個平台上的每個編解碼器都停用 B 格。
• GOP／關鍵格間隔。較長的 GOP（關鍵格之間間隔較多畫格）壓縮效果較好。較短的 GOP 則能更快從封包遺失中復原。Remio 實質上使用無限長的 GOP，並在解碼器回報遺失時向主機要求新的關鍵格。遺失的封包如果還來得及抵達，就會立刻重送；如果來不及，Remio 會直接略過它並要求新的畫格，而不是等待。這與我們「只渲染最新畫格」的串流理念一致。
• 前瞻。NVENC、AMF 與 QuickSync 都支援用於自適應量化的多格前瞻。每一格前瞻都會多出整整一格的延遲。Remio 使用零格或單格前瞻 — 每個編碼器的最低設定。
• VBV 緩衝區。Video Buffering Verifier 視窗，決定編碼器在回到目標位元率之前，被允許「向前借用」多少位元。較大的 VBV 讓畫質較平滑；較小的 VBV 讓位元率控制更緊湊、延遲更低。Remio 使用 1 格的 VBV — 即位元率除以畫面更新率 — 這是合法的最小值。

這個規律在四家廠商之間是一致的。即時低延遲是一個受約束的最佳化問題：你放棄離線編碼中前瞻與 B 格所換得的那幾個百分點畫質，換取即時互動所需的可預期延遲。每一個上市的串流產品 — Remio、Parsec、NVIDIA GeForce NOW、Xbox 雲端遊戲 — 都在相同的方向上做出相同的取捨。

你（使用者）真正需要在意的事

如果你直接跳到結尾：任何現代 GPU 的硬體編碼器，用於遠端桌面都沒問題。

在即時設定下的差異，小於任何合理基準測試的雜訊底線。使用 Pascal GTX 1060 的使用者，與使用 RTX 4090 的使用者，得到的 Remio 體驗相同 — 兩者都能以約 8 毫秒的處理延遲跑滿 120 FPS 管線（其餘是你的螢幕本身 60 Hz 的更新節奏），在區域網路位元率下產生的輸出也無從分辨。

例外情況，依出現頻率排序：

• 具備 AV1 能力的硬體，一般來說對慢速網路有幫助。在旅館 Wi-Fi 或行動熱點上，Ada / RDNA3 / Arc 主機搭配 M3+ 或 RTX 40 系列用戶端，在有使用它的工具上，相同畫質下可多出約 25% 的餘裕。在區域網路上則毫無差別。Remio 目前還不執行 AV1 — 端對端 H.265 就是整條管線 — 所以今天這是廠商的優勢，而不是 Remio 的優勢。
• Apple 晶片 Mac 是非常出色的主機。媒體引擎的低延遲、出色的 H.265，以及 3–5 W 的耗電，讓 Mac mini 或 Studio 成為你能買到的最佳常駐串流來源之一。沒有 AV1 編碼是唯一的缺口，在區域網路上無關緊要。
• Intel Arc A380 在 AV1 上是不合理的划算。約 120 美元就能買到一個勝過 400 美元以下任何東西的編碼區塊。
• libx264 CPU 備援是真的能用。沒有硬體編碼器 — 舊筆電、沒有內顯的伺服器 — Remio 仍然能運作。只是無法達到 4K 60，也無法不佔用一個 CPU 核心。

除了這些邊緣情況，正確答案就是最簡單的那個：使用你本來就會買的 GPU。每一家現代廠商都已趨同於相同的能力、相同的低延遲預設、相同的畫質範圍。Remio 會在執行階段選出正確的那一個，你不必費心。去做你開啟遠端桌面連線原本要做的事吧 — 寫程式、剪輯影片、修伺服器、在咖啡店推送修正。

這就是固定功能矽晶片的全部意義。它就是能運作，然後你不再注意到它。