NAS 的「媒體伺服器」怎麼設：Plex 與 Jellyfin 的轉碼效能對比
結論很簡單：在 NAS 這種低功耗平台上，硬體轉碼不是「加分項」，而是「必需品」。這也是 Plex 與 Jellyfin 效能差異的真正戰場。
二、Plex 與 Jellyfin 的定位差異
兩套軟體師出同源，都與早期的 XBMC / Kodi 生態有淵源，但走向了完全不同的路線。理解它們的商業模式與設計哲學，才能理解為什麼在轉碼功能上會有不同的限制。
2-1 Plex：成熟生態與商業模式
Plex 由 Plex Inc. 經營，屬於商業軟體（採免費增值模式）。它的核心優勢在於「體驗」：介面精緻、電影海報與演員資訊自動抓取準確、跨平台客戶端涵蓋幾乎所有裝置——Samsung、LG 智慧電視內建 App、Apple TV、Android TV、Chromecast、遊戲主機、手機、平板，甚至車機。
遠端存取也是 Plex 的強項，透過 Plex Relay 中繼服務，即使沒有固定 IP、不會設定路由器 Port Forwarding，也能在外網連回家中伺服器。對於不想折騰的使用者，這是巨大的便利。
但便利是有代價的。硬體轉碼功能屬於 Plex Pass 訂閱權益（有月費、年費與終身買斷方案，實際價格與權益請以官方公告為準）；此外 Plex 必須綁定 plex.tv 雲端帳號才能登入，2025 年起遠端串流也需要額外的付費授權。對重視隱私或不想長期付費的使用者，這些都是門檻。
2-2 Jellyfin：完全開源與隱私優先
Jellyfin 是 2018 年從 Emby 分支出來的專案，起因是 Emby 走向閉源。Jellyfin 採用 GPL 授權，完全免費、沒有付費牆、沒有功能分級，所有功能包括硬體轉碼、硬體解碼、使用者管理、DLNA、外掛系統全部開放。
它不需要雲端帳號，所有使用者帳號都建立在自己的伺服器上，觀看紀錄、收藏清單不會上傳到任何第三方。對於把 NAS 當成私人影音庫、在意資料主權的人來說，這點極具吸引力。
代價是「折腾成本」較高。智慧電視的 App 支援較弱（LG webOS、Samsung Tizen 多為社群維護版本，需要手動安裝），iOS 端需使用第三方客戶端，遠端存取得自行架設反向代理、VPN 或 Tailscale。硬體加速也必須手動啟用，預設是關閉的。
2-3 費用、帳號與隱私的現實比較
比較項目
Plex
Jellyfin
授權模式
免費增值，硬體轉碼需 Plex Pass
完全免費開源（GPL）
帳號系統
需綁定 plex.tv 雲端帳號
純本地帳號，無雲端依賴
硬體轉碼
需訂閱，支援 QSV / NVENC / AMF / VideoToolbox
客戶端涵蓋
極廣，智慧電視原生支援
較窄，電視端多需手動安裝
遠端存取
內建 Relay 中繼，設定簡單
需自行設定反向代理或 VPN
外掛生態
官方外掛商店，審核較嚴
社群外掛豐富，自由度高
隱私
需連外驗證，曾發生資料外洩事件
完全本地，無外連需求
三、轉碼效能實測對比：硬體平台決定一切
接下來進入本文核心。同樣是 4K HEVC 轉 1080p H.264，在不同硬體上跑 Plex 與 Jellyfin，結果可能天差地遠。原因不只是軟體實作，更在於兩者對硬體加速 API 的支援深度與預設值差異。
3-1 Intel Quick Sync Video（QSV）：NAS 的性價比之王
如果你用的是 Synology、QNAP、Asustor 的 Intel 機型，或自組的 N100、i3、i5 平台，QSV 幾乎是唯一現實選擇。它的優勢是內建於 CPU、不佔額外插槽、功耗極低，且 Intel 對編解碼格式的支援在近幾代進步神速。
以下是各世代 QSV 的關鍵能力，這直接決定了你能轉什麼格式：
在 Plex 上，QSV 的啟用相對簡單，只要訂閱 Plex Pass 並在設定中勾選硬體加速即可，Plex 會自動辨識並使用。在 Jellyfin 上，則需要在「控制台 → 播放 → 硬體加速」中選擇 QSV 或 VA-API，並逐一勾選要啟用解碼的格式，設定較繁瑣但彈性更高。
實務上，Intel 內顯的硬體轉碼品質在低碼率時較軟體 x264 略糊，但若目標碼率設定在 4~8 Mbps 的 1080p，肉眼差異有限。真正需要注意的是同時轉碼路數：以 J4125 這類低階四核為例，1080p H.264 轉碼約可同時處理 2~4 路；N100 因架構較新，可達 4~6 路；而 4K HEVC 轉 1080p 則往往只能勉強 1~2 路，還要看是否開啟色調映射。
3-2 NVIDIA NVENC 與 AMD VCN：外接顯卡的另一條路
如果你的 NAS 有 PCIe 插槽（例如自組的 Unraid、TrueNAS，或部分 QNAP、Asustor 機型），加裝獨立顯卡是提升轉碼能力的捷徑。NVIDIA 的 NVENC 單元在 Turing 架構（GTX 16 系列、RTX 20 系列）之後畫質大幅提升，Ada 架構更支援 AV1 編碼，轉碼效率遠勝同價位的內顯。
但要注意幾個現實問題。第一，NVIDIA 消費級顯卡的驅動程式對「同時 NVENC 編碼 session 數」設有上限，雖然近年已放寬，但大量並行轉碼仍可能受限，專業卡（Quadro / RTX A 系列）則無此限制。第二，獨立顯卡功耗動輒 75W 以上，對原本設計為低功耗的 NAS 來說，電源與散熱都需要重新評估。第三，部分 NAS 機殼空間有限，半高單槽卡是唯一選擇。
AMD 方面，Ryzen APU 內建的 VCN 單元在 Jellyfin 上透過 Mesa 的 VA-API 驅動運作良好，支援 HEVC 編解碼；但 Plex 對 AMD 硬體加速的支援相對較晚也較不穩定，實務上建議 AMD 平台優先考慮 Jellyfin。至於 Rockchip RK3588 這類 ARM 單板電腦，Jellyfin 有原生 RKMPP 支援，是低功耗愛好者的另類選擇。
3-3 常見 NAS 機種與處理器的轉碼能力參考
下表整理社群常見機種的硬體轉碼能力，供選購或設定時參考。實際表現會受影片碼率、字幕、同時連線數與軟體版本影響，數值僅為約略參考。
平台 / 機種範例
內顯
1080p 轉碼（約）
4K HEVC 轉 1080p（約）
備註
Celeron J4125（DS920+、DS224+ 等）
UHD 600
2～4 路
1 路，吃力
不支援 HDR 色調映射加速
Pentium N6005 / Celeron N5095
UHD（Jasper Lake）
3～5 路
1～2 路
支援 HEVC 10bit 解碼
Intel N100 / N305（Alder Lake-N）
UHD 24EU
4～6 路
2 路左右
支援 AV1 解碼，CP 值高
Intel i5-12400 / i5-13500
UHD 730 / 770
8 路以上
3～5 路
適合多人共用
AMD Ryzen R1600（DS923+ 等）
無內顯
純軟體，極有限
不建議
需外接顯卡或走 Direct Play
NVIDIA GTX 1650 / RTX 3050
NVENC
10 路以上
4～6 路
功耗較高，需注意電源
Intel Arc A380
Xe（AV1 編碼）
10 路以上
5 路以上
需較新核心與驅動
特別提醒：Synology 自 DSM 7.2.2 起移除了 Video Station 與部分機型的 HEVC 解碼支援，讓不少使用者轉向 Plex 或 Jellyfin。若你打算在 Synology 上跑硬體轉碼，務必先確認機型是否有內顯，以及套件是否取得 video 群組權限。
3-4 4K HDR、色調映射與字幕燒錄的效能陷阱
很多人的 4K 轉碼體驗「理論上可行、實際上卡爆」，問題通常出在三個隱形殺手。
第一是色調映射（Tone Mapping）。4K HDR 影片的亮度資訊（PQ / HLG）必須轉換成 SDR 才能讓一般螢幕正確顯示，這個轉換極度吃運算資源。Plex 在部分平台有較成熟的支援，Jellyfin 則需要 OpenCL 加速，而 Intel 內顯的 OpenCL 驅動在 NAS 環境中經常安裝不良或效能低落，導致 tone mapping 一開就掉格。若你的觀眾端都支援 HDR，最省事的做法是關閉 tone mapping，讓播放端自行處理。
第二是圖形字幕燒錄。PGS（Blu-ray 圖形字幕）與部分的 ASS 特效字幕無法由播放端自行渲染，伺服器必須把字幕「畫」進影片畫面，這等於強制轉碼，而且像素處理讓效能需求再往上跳一級。SRT 這類純文字字幕若播放端支援，就能走 Direct Play，零成本。
第三是 10bit 編碼。若你的硬體只支援 10bit 解碼、不支援 10bit 編碼（例如第 7～9 代 Intel），遇到 10bit 片源時軟體會降轉成 8bit，畫質與效能都會受影響。第 10 代以後的平台才完整支援 HEVC 10bit 編碼。
四、NAS 實戰安裝與設定
理解原理後，接著進入實際部署。以下以 Synology DSM 與 Docker 環境為主，其他品牌（QNAP、Asustor、TrueNAS、Unraid）的操作邏輯相近，差異主要在套件管理與裝置權限。
4-1 Plex 安裝與硬體轉碼啟用
Plex 在 Synology 上有官方套件，可從套件中心或官網下載 SPK 安裝。安裝完成後，第一步是到 DSM 的「控制台 → 使用者與群組」，將 PlexMediaServer 這個系統使用者加入 video 群組，這是硬體轉碼能否成功的關鍵，少了這步 Plex 會找不到 /dev/dri 裝置。
接著進入 Plex 網頁介面，依序點選「設定 → 轉碼器」，勾選「Use hardware acceleration when available」，並將「Enable hardware-accelerated video encoding」一併開啟。若你的平台支援 HDR，可再確認色調映射選項。最後別忘了設定「轉碼器臨時目錄」，建議指向 SSD 或 RAM Disk，避免轉碼暫存檔塞滿硬碟陣列並造成頻繁寫入。
Plex 的優點是自動辨識能力強，多數情況下不必手動指定 API。若硬體轉碼沒生效，可查看伺服器日誌中是否有 TPU: hardware transcoding 相關字樣，或到播放時的「資訊」面板確認是否顯示 (hw) 標記。
4-2 Jellyfin 安裝與硬體加速設定
Jellyfin 在 Synology 上可透過社群套件庫（SynoCommunity）或 Docker 安裝；QNAP 可用 Container Station；自組平台則直接以 Docker Compose 部署最為乾淨。
安裝完成進入控制台後，路徑是「控制台 → 播放 → 硬體加速」。這裡要做的設定比 Plex 多：
允許的轉碼路數：可限制同時轉碼數量，避免 NAS 被吃垮。
Jellyfin 的彈性高，但也意味著設定錯誤時更容易出問題。建議每更動一項設定就實際播放一次，確認日誌中出現 Hardware decode 或 VAAPI 等字樣，逐步排查。
4-3 Docker 部署與裝置權限
Docker 部署是跨平台最一致的方式，關鍵在於把 GPU 裝置掛進容器，並給予正確的群組權限。以下為 Intel 平台的 Compose 範例：
services:
jellyfin:
image: jellyfin/jellyfin:latest
container_name: jellyfin
restart: unless-stopped
devices:
- /dev/dri:/dev/dri
group_add:
- "989" # render 群組 GID，請依主機實際數值調整
volumes:
- ./config:/config
- ./cache:/cache
- /volume1/media:/media:ro
ports:
- "8096:8096"
其中 /dev/dri 是 Linux 的 Direct Rendering Infrastructure 裝置節點，Intel 與 AMD 的硬體加速都靠它。group_add 的數值可在主機上執行 getent group render 查詢，不同發行版與 NAS 系統可能不同。若沒掛載成功，Jellyfin 的硬體加速選項會反灰無法啟用，或播放時直接退回軟體解碼。
對於 Synology 的 DSM，還需注意 Docker 版本的權限模型差異；部分較新版本改用 Container Manager，掛載裝置的路徑與權限設定位置略有不同。部署完成後，建議先用一段 4K HEVC 短片測試，观察 CPU 使用率是否維持在低檔——若轉碼時 CPU 仍然滿載，代表硬體加速沒有真正生效。
五、效能調校與常見問題排查
設定完成不代表一勞永逸。實際使用中，最常見的狀況是「明明開了硬體加速，還是卡」。以下整理幾個實戰調校重點。
5-1 為什麼轉碼會卡？五個常見原因
排查順序建議：先確認播放資訊面板顯示的是 Direct Play 還是 Transcode，再看轉碼是否標註硬體加速，最後才檢查網路與儲存效能。大部分問題在前兩步就能定位。
5-2 字幕與音軌的處理策略
字幕是影響轉碼比例最大的變數。策略上，優先選擇播放端能自行渲染的 SRT、WebVTT 等文字字幕；遇到 PGS 圖形字幕時，若播放端支援就讓它走 Direct Play，不支援才交給伺服器燒錄。Jellyfin 與 Plex 都提供「僅在必要時燒錄圖形字幕」的選項，建議開啟。
音軌同理。TrueHD、DTS-HD MA 這類無損音軌頻寬大、解碼要求高，若播放端只是電視喇叭或手機，伺服器會將其轉成 AAC 或 AC3。這類音訊轉碼負載不高，但會讓原本可 Direct Play 的影片變成轉碼，連帶觸發視訊重編碼。若你的設備不支援無損音軌，可在設定中指定優先使用相容音軌，避免不必要的轉碼。
5-3 暫存、快取與網路頻寬
轉碼暫存目錄建議獨立於資料碟之外。放在 SSD 上可大幅降低等待時間，放在 RAM Disk 則更快，但要留意容量是否足夠——高碼率 4K 轉碼的暫存檔可能短時間內膨脹到數 GB。若暫存目錄與影片庫共用同一顆硬碟，轉碼的讀寫會與串流讀取互搶 I/O，造成卡頓。
網路方面，若家庭成員多、同時觀看 4K 內容，建議升級至 2.5GbE 或 10GbE 環境，並確保交換器與線材支援。無線播放則至少需要 Wi-Fi 5 以上、5GHz 頻段，且避免與大量裝置共用頻寬。此外，Plex 與 Jellyfin 都會產生縮圖預覽（Chapter Thumbnail），這個功能在背景掃描時非常吃 CPU，建議設定在離峰時段執行或直接關閉。
六、該選 Plex 還是 Jellyfin？依情境給建議
談完效能與設定，最後回到選擇題。其實沒有絕對答案，關鍵是你的使用情境與願意投入的時間。
選 Plex 的情況：家中有長輩或非技術背景成員，需要「打開電視就能看」的體驗；家中有多品牌智慧電視，不想一台一台手動安裝 App；需要簡單的遠端存取，不想研究反向代理與憑證；願意為省事支付訂閱費。Plex 在客戶端覆蓋率與使用者體驗上仍有明顯優勢，硬體轉碼的啟用也較為直覺。
選 Jellyfin 的情況：重視隱私，不希望帳號與觀看紀錄經過第三方伺服器；不想長期訂閱，或使用 AMD 平台、Rockchip 平台等 Plex 支援較弱的硬體；喜歡折騰、願意花時間調校；家庭成員都是技術使用者，能自行安裝客戶端。Jellyfin 完全免費且硬體加速無功能限制，長期成本最低。
兩者都適合的情況：如果你的影片庫以 H.264 1080p 為主，播放端也都支援，那麼轉碼需求極低，兩套軟體的效能差異幾乎感受不到，此時選擇就純粹看介面偏好與隱私考量。
兩者都不適合的情況：若你的 NAS 是無內顯的 AMD 機型（如部分 Ryzen 機種），且影片庫以 4K HEVC 為主，那麼無論裝哪一套，都只能靠軟體轉碼硬撐，體驗都不會好。此時更務實的做法是：確保播放端支援 Direct Play、使用支援 HDR 的播放器（如 Apple TV 4K、NVIDIA Shield），或考慮加裝具備硬體解碼能力的設備。
七、結論
NAS 媒體伺服器的順暢與否，八成取決於硬體轉碼能力，兩成取決於軟體設定。Plex 與 Jellyfin 在轉碼效能的「上限」其實相差無幾——同樣的 Intel QSV 或 NVIDIA NVENC 晶片，兩者都能發揮接近的效能；真正的差異在於啟用門檻與支援成熟度。Plex 用訂閱費換取一鍵設定的便利，Jellyfin 用設定時間換取完全免費與隱私自主。
給準備入門的讀者三個實務建議。第一，選購 NAS 時務必確認處理器是否有內顯且支援目標格式的硬體編解碼，這比核心數更重要。第二，安裝完成後一定要實際播放並確認轉碼標記，不要假設「勾了就會生效」。第三，優先讓播放端走 Direct Play，把轉碼視為備援而非預設，才是讓 NAS 長久穩定運作的關鍵。
搞懂原理、選對硬體、設對參數，你的 NAS 就能從「檔案倉庫」升級為真正的家庭影音中心。無論最後選擇 Plex 還是 Jellyfin，能順暢播放的那一套，就是最適合你的那一套。
```
💬 想說點什麼？
歡迎到留言板分享你的想法、心得或疑問。
💬 前往留言板 →