Jellyfin (二) 硬件加速 feat Synology NAS

上一集，我們提到了一個專業的影音平台通常都是靠 GPU 硬件加速來處理用戶們的影音串流工作，其中在伺服器端的處理器為重中之重，為此我們特別找來了配置 Intel Celeron J3455 處理器的 Synology DS918+ 作為本次 Jellyfin 的載體，以驗證 GPU 硬件加速的功能。

Synology 上安裝 Jellyfin

原 Synology 套件中心裡的「Docker」已改名為「Container Manager」，先安裝此套件，以便後續使用 docker-compose 來安裝 Jellyfin

確認所需的共用資料夾，其中在 docker 目錄裡新增 JellyFin 目錄，並於 JellyFin 目錄中再新增 cache 和 config 兩個目錄以供稍晚建置的容器使用，同時本次示範所需的影音媒體檔案則放置於共用資料夾下方的 Jellyfin 目錄裡

Container Manager 中建立新專案

專案所需的 docker-compose.yaml 如下，本次使用的映像檔為 Jellyfin 開發團隊中的成員 nyanmisaka 所額外建立的特供版，此版本基於原版的 Jellyfin 映像檔並添增了最新的顯示驅動、媒體庫中文字體（解決字體變成方塊的問題），貼心的解決了我們在硬件加速上所需執行的各種繁雜瑣碎系統操作

version: '3'
services:
  jellyfin:
    # 拉取最新特供版的Jellyfin映像檔
    image: nyanmisaka/jellyfin:241027-amd64
    container_name: jellyfin
    # 以root使用者執行服務
    user: root:root
    network_mode: 'host'
    volumes:
    # 將Jellyfin設定檔和縮圖的存放至指定目錄
      - "/volume1/docker/JellyFin/config:/config"
      - "/volume1/docker/JellyFin/cache:/cache"
    # 參考下面格式，將存放影音檔案的磁碟目錄(冒號左邊)依序掛載給Jellyfin容器內部的目錄，以此類推
      - "/volume1/Jellyfin:/media:ro"    
    # GPU直通、硬件加速
    devices:
      - /dev/dri/card0:/dev/dri/card0
      - /dev/dri/renderD128:/dev/dri/renderD128
    # 開機自動啟動容器
    restart: 'unless-stopped'
    environment:
    # 除非您有自己的域名，否則不需這行
      - JELLYFIN_PublishedServerUrl=http://movies.example.com
    extra_hosts:
      - "host.docker.internal:host-gateway"

核顯直通容器

Synology 確認已經開啟：

控制台 > 終端機 & SNMP > 啟用 SSH 功能

連線至 Synology 中確認核顯裝置路徑（此處需配合 docker-compose 文件所掛載的 devices 路徑）

[tomy@terminal ~]$ ssh admin@192.168.100.250
admin@192.168.88.250's password: 

Using terminal commands to modify system configs, execute external binary
files, add files, or install unauthorized third-party apps may lead to system
damages or unexpected behavior, or cause data loss. Make sure you are aware of
the consequences of each command and proceed at your own risk.

Warning: Data should only be stored in shared folders. Data stored elsewhere
may be deleted when the system is updated/restarted.

admin@ds918:~$ sudo su
Password: 
ash-4.4# ls /dev/dri/ -lah
total 0
drwxr-xr-x  2 root root              80 Oct 29 14:45 .
drwxr-xr-x 12 root root             14K Oct 29 14:47 ..
crw-------  1 root root        226,   0 Oct 29 14:45 card0
crw-rw----  1 root videodriver 226, 128 Oct 29 14:45 renderD128

參考 Intel Quick sync video 的 Wiki資料，於 Jellyfin 控制台中開啟硬件加速並勾選與處理器匹配的解碼選項（本例採用的是 Apollo Lake 世代的 Intel Celeron J3455 處理器）

驗證硬體加速功能

以 Android 手機的 Jellyfin APP 為範例，預設以 Exo player 播放影片，在開啟硬件加速的情況下，Synology 的資源使用狀況如下，可以看到容器的資源消耗僅有1％，NAS 整體的 CPU 使用率為 8％（本例的處理器為 4核心）

片源大小為 8GB、1080P 解析度，播放方式為客戶端「直接解碼」，以 4G網速在外觀賞影片，因為流量的關係播放時會有稍微的卡頓

不得已我們將流量碼率調降為 480P 已取得較流暢的播放體驗

可以看到伺服器端已經開始進行轉碼

記錄一下我們 NAS 的資源使用變化，總體來說系統整體的 CPU 使用率上升了 31％

從 Jellyfin 控制台裡的「日誌」可以看到，此時 QSV 硬件加速已經介入了

Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_qsv))
  Stream #0:1 -> #0:1 (dts (dca) -> mp3 (libmp3lame))

接下來我們到 Jellyfin 控制台裡取消勾選硬件加速再試試看，由於單純的串流傳送封包並不會消耗過多的運算資源，此時 NAS 的整體資源消耗並無太大差異

然後我們一樣將流量碼率調整為 480P，結果 NAS 整體的 CPU 資源消耗從原本的 39% 暴漲到了 96％，而容器的資源消耗從原本的 100％直接幹到了 340%

由於沒有硬件加速的關係，從日誌中也可以看到，Jellyfin 目前只能使用軟體解編碼

Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
  Stream #0:1 -> #0:1 (dts (dca) -> mp3 (libmp3lame))

結語

也許剛好你手邊建置 Jellyfin 的硬體條件不一定都能吻合硬件加速的需求，但影音串流的過程中是否需要轉碼？是否需要硬件加速？這也和客戶端的匹配息息相關，以家中內網來說，基本不存在流量問題，也就不需要考慮降碼觀影，那麼會觸發轉碼的機會就只有當客戶端媒體播放器不認識原始片源的編碼格式時才會發生，如果說我們準備好了功能相對完善的客戶端媒體播放器？是不是就沒有轉碼、大量運算資源佔用、播放卡頓的問題了呢？

Jellyfin 之所以是一個熱門的影音串流平台解決方案，正是因為它提供了幾乎全平台的裝置，TV端有 Android Jellyfin、Kodi 等客戶端播放器、手機端有 Findroid、Jellyfin APP 搭配 MX Player 或是 VLC 播放器、Linux 和 Windows 還有 Jellyfin Media Player 應用程式…等各式各樣的選擇，也許 VLC 無法順利解碼的來源，但換成 MX Player 就可以順利播放了呢！

至此，關於 Jellyfin 的基礎建設建置和一些影音串流原理的部分我們就講解完畢了，下一集！我們會將你硬碟深處最隱密的小姐姐帶入你的 Jellyfin ，讓你做一回真正的男人！

本文內容參閱以下連結：

Jellyfin 中国特供版 + Docker 镜像

群晖 Docker 安装 Jellyfin 媒体服务器并开启 Intel Quick Sync 提升性能

用 Docker 自架可調畫質 + 硬體解碼的影片音樂串流伺服器