著者 Matt Connor
JellyfinのNVIDIA GPUハードウェアトランスコード設定
Docker ComposeでJellyfinコンテナにNVIDIA GPUを割り当て、NVENCとNVDECを有効化します。nvidia-smiでGPUが実際にトランスコードへ使われているか確認する手順です。
構築するもの
NVIDIA GPUでJellyfinのハードウェアトランスコーディングを構成する手順は、決まった順序の4段階です。Jellyfin内で行うのは最後の段階だけです。ホストでドライバーが読み込まれていなければ、コンテナからGPUは見えません。コンテナから見えないGPUを、Jellyfinは使用できません。この順序で進めると、各エラーを確認すべき場所が明確になります。
- ホストにNVIDIAドライバーをインストールし、
nvidia-smiで動作を確認します。 - NVIDIA Container Toolkitをインストールし、DockerからコンテナへGPUを割り当てられるようにします。
docker-compose.ymlでJellyfinサービス用にGPUを確保し、コンテナからGPUが見えることを確認します。- Jellyfinの再生設定でNVENCとNVDECを有効にし、実際の再生で使用されることを確認します。
NVENC（NVIDIA encoder）とNVDEC（NVIDIA decoder）は、GPU上の固定機能ブロックです。CUDA（compute unified device architecture）の処理を実行するシェーダーコアとは、別の回路です。この分離が、ハードウェアトランスコーディングを導入する主な理由です。ソフトウェア処理ではCPUコアを複数消費するストリームでも、GPU上の専用ハードウェアブロックと、1つのCPUコアの一部だけで処理できます。
Direct play は、どのトランスコードよりも優先されます。まずこれを確認してください
この設定を行う前に、単に取り除ける理由でトランスコードしていないか確認します。Jellyfin は、クライアントがファイルをそのまま再生できない場合にトランスコードします。理由は、常に次のいずれかです。ビデオコーデック、オーディオコーデック、コンテナ形式、画像ベースの字幕、またはクライアントが要求したビットレート制限です。
Dashboard を開き、Playback に移動して、何かを再生している間にアクティブなセッションを確認します。Direct playing と表示されたセッションはファイルを変更せずに送信するため、CPU 使用率はほとんど増えません。Transcoding と表示されたセッションには、Jellyfin が選択した理由が示されます。その理由を取り除けば、GPU を実行する必要はありません。
ほとんどのトランスコードは、2 つの変更でなくせます。クライアントアプリの画質を Auto または最大値に設定します。クライアントが 4 Mbps を要求すると、ファイルがどのコーデックを使用していても、20 Mbps のファイルは再エンコードされるためです。次に、ブラウザーのタブではなくネイティブクライアントアプリを使用します。ブラウザーは利用できるプレーヤーの中で最も制限が多く、同じ TV 上のネイティブアプリなら、同一ファイルをそのまま再生できることが多いためです。
画像ベースの字幕は、クライアント設定では解決できない例外です。Blu-ray リッピングの PGS 字幕と DVD リッピングの VOBSUB は画像なので、ビデオ自体に描画する必要があります。そのため、ビデオストリーム全体の再エンコードが発生します。SRT のテキスト字幕は別トラックとしてクライアントに送信されるため、負荷はほとんどありません。可能な場合は、字幕トラックをテキストに変換するほうが GPU の導入より効果的です。サーバー側の残りの設定については、VPS 上で Jellyfin メディアサーバーを運用するガイドで説明しています。
一般的な VPS プランには GPU がありません
標準的な VPS プランには GPU が含まれていません。ほかの計画を立てる前に、サーバー上で次を実行してください。
lspci -nn | grep -Ei "3d|display|vga"一般的な KVM VPS では、ハイパーバイザーが提供する仮想ディスプレイアダプターが表示されるか、有用な情報が何も表示されません。このデバイスでは動画をエンコードできません。実際の GPU が利用できるのは、プロバイダーが物理カードをインスタンスにパススルーする場合、または GPU の一部を割り当てる場合だけです。そのため、これらのプランは相応の料金になります。GPU VPS に料金を支払う価値があるワークロードとはでは、GPU VPS を選ぶべき利用者と、選ぶ必要がない利用者について説明しています。
GPU がない場合は、ダイレクトプレイを基本にし、ソフトウェアトランスコードは例外的なケースとして扱ってください。単一の 1080p H.264 ソフトウェアトランスコードは負荷が高いものの、数個の CPU コアで処理できます。トーンマッピングを伴う 4K HDR のソフトウェアトランスコードを小規模な VPS でリアルタイムに完了することはできません。そのため、CPU 使用率が 100 percent に張り付く間、ストリームは途切れます。
ホストに NVIDIA ドライバーをインストールする
Jellyfin 10.11 のドキュメントでは、Linux に必要な NVIDIA ドライバーの最小バージョンを 520.56.06 としています。Ubuntu には、適合するパッケージを自動で選択するヘルパーが用意されています。
sudo ubuntu-drivers list --gpgpu
sudo ubuntu-drivers install --gpgpu
sudo reboot--gpgpuはドライバーのヘッドレスサーバー用フレーバーを選択します。デスクトップ環境のないメディアサーバーでは、このフレーバーを使用します。list コマンドは利用可能なブランチを表示します。名前を指定して、例えば sudo ubuntu-drivers install --gpgpu nvidia:570-server のように 1 つのブランチを固定できます。ここに記載したものではなく、list コマンドで実際に表示されたブランチを使用してください。
サーバー用フレーバーでは、nvidia-smiが常にインストールされるとは限りません。選択したブランチに対応する utils パッケージを、例えば sudo apt install nvidia-utils-570-server のようにインストールしてください。その後、ドライバーを確認します。
nvidia-smi正常な結果では、ヘッダーにドライバーのバージョンと CUDA のバージョンを含む表が表示され、カードが名前付きで一覧に表示されます。プロセス一覧は空です。ここでは、2 つの問題がよく発生します。nvidia-smi: command not foundは utils パッケージが不足していることを示します。ドライバー自体の問題ではありません。NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driverはカーネルモジュールがロードされていないことを示します。新規インストール直後の場合、ほぼ常に、まだ再起動していないか、Secure Boot によって署名されていないモジュールのロードが拒否されています。lsmod | grep nvidiaでモジュールが存在することを確認してください。
NVIDIA Container Toolkit をインストールする
ドライバーにより、ホストは GPU を使用できます。ただし、コンテナにはデバイスノードもドライバーライブラリもないため、Docker は GPU をコンテナに渡せません。NVIDIA Container Toolkit は、コンテナの起動時にこれらを注入します。以下は、NVIDIA が Debian と Ubuntu 向けに提供しているインストールコマンドです。
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkitパッケージをインストールするだけでは不十分です。Docker にランタイムの存在を認識させる必要があります。
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart dockernvidia-ctk runtime configure は、/etc/docker/daemon.json に nvidia ランタイムのエントリを書き込みます。再起動は省略されがちですが、省略すると、この構成全体で最もよくあるエラーが発生します。Jellyfin の設定に進む前に、連携が機能することをテストしてください。
sudo docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smiホストで表示されたものと同じテーブルが表示されるはずです。代わりに gpu capabilities を持つデバイスドライバーを選択できないというエラーが表示された場合、Docker daemon が nvidia runtime を認識していません。そのため、設定コマンドを再度実行してから daemon を再起動してください。
Docker Compose で Jellyfin コンテナに GPU を割り当てる
これは、Jellyfin が公開している例に対応した最新の Compose 形式です。
services:
jellyfin:
image: jellyfin/jellyfin
container_name: jellyfin
user: 1000:1000
network_mode: host
restart: unless-stopped
environment:
- NVIDIA_VISIBLE_DEVICES=all
- NVIDIA_DRIVER_CAPABILITIES=all
volumes:
- /srv/jellyfin/config:/config
- /srv/jellyfin/cache:/cache
- /srv/media:/media:ro
runtime: nvidia
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]コンテナを起動し、コンテナ内から直接確認します。
docker compose up -d
docker compose exec jellyfin nvidia-smiコンテナ内からドライバーの一覧が出力されれば、GPU は正しく渡されています。残る問題はすべて Jellyfin の設定にあります。
このファイルにある 4 行には、説明が必要です。capabilities: [gpu] は Compose 自体に必要です。省略すると、GPU なしでサービスを起動するのではなく、Compose がサービスを拒否します。NVIDIA_DRIVER_CAPABILITIES=all も重要です。video capability を要求した場合に限り、toolkit は video library をコンテナ内にマウントします。また、Jellyfin のドキュメントでも、この変数は公式イメージに必須とされています。これがないと CUDA は動作しても NVDEC は動作せず、トランスコードログに Cannot load libnvcuvid.so.1 と出力されます。network_mode: host は Jellyfin 自身の例で使用されています。bridge network では、UDP port 7359 を使用するクライアントの自動検出が機能しないためです。
最後が user: 1000:1000 です。これは GPU とは関係ありません。メディアの mount 上で Jellyfin が読み取れるファイルを決めます。ここが一致しない場合、権限エラーではなく library が空になります。PUID と PGID がコンテナユーザーをディスク上のファイルに対応付ける仕組みでは、この番号付けについて説明しています。Docker Compose で Sonarr と Radarr の stackを並行して運用している場合も、すでに設定したものと同じ番号付けを使用します。
多くのチュートリアルが今でも runtime: nvidia と記載する理由
古い形式は、現在でも多くのガイドに登場します。間違いではありません。これは経緯によるものです。元の nvidia-docker2 パッケージは nvidia という OCI runtime を登録していたため、コンテナで GPU を使用する唯一の方法は、--runtime=nvidia と NVIDIA_VISIBLE_DEVICES の組み合わせでした。Docker 19.03 で --gpus フラグと、適切なデバイス要求 API が追加されました。Compose の対応にはさらに時間がかかりました。対応した際、デバイス要求は deploy.resources.reservations.devices の下に配置されました。これは、多くの人が無視するようになっていたキーです。deploy は以前、Docker Swarm を意味していたためです。
その結果、現在はどちらの形式も使用でき、Jellyfin が公開している例では両方が同時に使われています。runtime: nvidia を残してもコストはなく、古い Compose バージョンでもファイルが動作します。runtime: nvidia だけを残して deploy ブロックを削除する場合は、NVIDIA_VISIBLE_DEVICES=all を残す必要があります。このレガシーな経路は、注入するデバイスを環境変数から判断するためです。代わりに読み取るデバイス要求はありません。
Jellyfin で NVIDIA ハードウェアトランスコードを有効にする
ここまでの設定だけでは、Jellyfin が GPU を使用するようにはなっていません。Dashboard、Playback、Transcoding の順に開きます。Hardware acceleration で Nvidia NVENC を選択します。Enable hardware encoding にチェックを入れます。これを有効にしないと、Jellyfin は GPU でデコードした後、CPU でエンコードします。GPU に使用状況が表示される一方で CPU の負荷も高いという、分かりにくい状態になります。
Enable enhanced NVDEC decoder は、現在の NVDEC パスと従来の CUVID パスを切り替えます。有効なままにしてください。Dolby Vision を処理するには、NVDEC を使用するためにこの設定を有効にする必要があります。
Enable hardware decoding for では、実際に GPU がデコードできるコーデックだけにチェックを入れます。ここを誤るケースが多くあります。AV1 デコーダーを搭載していない GPU で AV1 にチェックを入れても、エラーメッセージは表示されません。Jellyfin はハードウェアデコードを要求しますが、実際には利用できないため、ソフトウェアデコードへフォールバックします。その結果、CPU 使用率が高く、GPU はほとんどアイドル状態になります。これは、GPU のパススルーが機能していない場合とまったく同じ状態に見えます。
このページ全体には、もう 1 つ制約があります。ハードウェアアクセラレーションは、同梱の jellyfin-ffmpeg ビルドでのみ機能します。FFmpeg のパスをシステムの FFmpeg に設定している場合、アクセラレーションが一部しか機能しないか、まったく機能しません。
GPU 世代でデコードおよびエンコードできるコーデック
これは、Jellyfin が NVENC と NVDEC について示している対応範囲です。デコードとエンコードは別々の機能であり、一方だけに対応する GPU もあります。
- H.264 8-bit: NVENC と NVDEC の両方を搭載したすべての NVIDIA GPU が、デコードとエンコードの両方に対応します。
- HEVC 8-bit: Maxwell 第2世代 (GM206) 以降で、デコードとエンコードに対応します。
- HEVC 10-bit: Maxwell 第2世代以降でデコードに対応します。ただし、エンコードに対応するのは Pascal 以降です。
- AV1: Ampere 以降でデコードに対応し、Ada Lovelace 以降でエンコードに対応します。
実運用で問題になりやすいのは、HEVC 10-bit の対応範囲が分かれる点です。Maxwell 世代の GPU は 4K HDR ファイルを GPU でデコードできますが、10-bit 出力をエンコードできません。そのため、Jellyfin は代わりに 8-bit H.264 へエンコードします。これは再生でき、多くのクライアントにとっても適切な選択です。2026 年時点では、GPU にかかわらず AV1 エンコードを選ぶ場面はほとんどありません。クライアント側の AV1 デコード対応はまだ限られており、そもそもトランスコードが必要なクライアントは、すでに再生に問題を抱えているためです。
トーンマッピングによってGPUが静かに再び飽和する理由
HDR（高ダイナミックレンジ）からSDR（標準ダイナミックレンジ）へのトーンマッピングは、GPUの余力を消費する設定です。その理由はアーキテクチャにあります。デコードはNVDECで実行されます。エンコードはNVENCで実行されます。トーンマッピングはどちらでも実行されません。シェーダーコア上で動作するCUDAフィルターです。シェーダーコアは、コンピュート処理も実行するGPUの汎用部分です。そのため、トーンマッピングが必要な4K HDRストリームでは、デコーダーとエンコーダーを使用し、そのうえでシェーダーにも負荷がかかります。
Jellyfinのドキュメントでは、HEVC 10-bitをデコードできるすべてのNVIDIA GPUでCUDAトーンマッピングを利用できるとされています。つまり、設定項目が表示され、動作するカードでも、4Kで処理を継続できるとは限りません。ストリームが開始した後にバッファリングし続け、安定しないことがあります。一方、nvidia-smiではエンコーダーの使用率がほとんど上がっていないように表示されます。
そのため、シェーダーの負荷は個別に監視する必要があります。
nvidia-smi dmon -s uこのコマンドは、sm、enc、decを個別の列に分けて、1秒ごとに1行を出力します。encとdecが低く、smの値が高い場合、固定機能ブロックには余力があり、ボトルネックはシェーダーです。つまり、負荷の原因はトーンマッピング、スケーリング、または字幕の焼き付けです。CUDAパスはDolby Vision profile 5もゼロコピーで処理します。これは重要です。ゼロコピーを使用しない場合、フィルター処理の各段階でフレームがシステムメモリへ移動し、その後GPUへ戻されるためです。この往復によって、すべてのフレームで帯域幅が消費されます。
コンシューマー向け NVENC のセッション上限が実際に制限するもの
The data behind this chart
[
{
"label": "GeForce RTX 5090",
"nvenc_engines": 3,
"max_encode_sessions": 12
},
{
"label": "GeForce RTX 4090",
"nvenc_engines": 2,
"max_encode_sessions": 12
},
{
"label": "GeForce RTX 4060",
"nvenc_engines": 1,
"max_encode_sessions": 12
}
]これらは 2026 年 8 月時点で NVIDIA が公開しているマトリックスの数値であり、ここで測定した値ではありません。GeForce カードは、モデルに関係なく、同時エンコードセッション数が 12 に制限されます。この上限はシリコンではなくドライバーに設定されています。NVIDIA はこれまでに何度も上限を引き上げているため、古いフォーラム投稿ではなく、現在のマトリックスを確認してください。カードによって実際に変わるのはエンジン数です。GeForce RTX 5090 には 3 基の NVENC エンジンが搭載され、GeForce RTX 4060 には 1 基が搭載されています。エンジン数が多いほど並列エンコードのスループットは向上しますが、セッション上限は増えません。
この上限が数えるのはエンコードセッションなので、トランスコードストリームだけが対象です。Direct Play とリマックスでは、エンコードセッションは開始されません。L4 などのデータセンター向けカードは、同じマトリックスで無制限と記載されています。GPU VPS プランで提供されるのも通常はデータセンター向けカードです。そのため、この上限は主にホームサーバーで問題になります。
上限に達するとトランスコードが失敗し、FFmpeg のログに OpenEncodeSessionEx failed: out of memory (10) が出力されます。このメッセージはメモリを示しますが、セッション数の上限による拒否でも同じコードが報告されます。そのため、VRAM リークを調べる前に、同時実行中のストリーム数を確認してください。実際には、多くの場合、12 セッションに達する前にトーンマッピングの上限かアップロード帯域幅がボトルネックになります。
GPU でトランスコードされていることを確認する
保存された設定は証拠になりません。トランスコードが必須になることを確認したファイルを再生し、3 つの確認を行います。
- Dashboard を開き、Playback に移動します。アクティブなセッションに Transcoding と表示され、理由も示されていることを確認します。Direct playing と表示される場合、トランスコードは行われていません。テストしているファイルが適切ではありません。
- Dashboard を開き、Logs に移動して、最新の
FFmpeg.Transcodeログを開きます。ハードウェアトランスコードの場合、コマンドラインに-hwaccel cudaと-hwaccel_output_format cudaが表示され、エンコーダーとしてh264_nvencまたはhevc_nvencが使われます。ここにlibx264が表示される場合、設定ページの表示に関係なくソフトウェアでトランスコードされています。 - 再生を続けたまま、ホスト上で
nvidia-smiを実行します。/usr/lib/jellyfin-ffmpeg/ffmpegのプロセスが GPU メモリを割り当てた状態で表示され、nvidia-smi dmon -s uの enc 列と dec 列が 0 以外の値を示すことを確認します。
3 つ目の確認は、コンテナ内ではなくホスト上で実行してください。コンテナ内の nvidia-smi は通常、独自の namespace 外にあるプロセス ID を参照できないため、空のプロセス一覧を表示します。一方、使用率の数値は正しく表示されます。コンテナ内でプロセス一覧が空でも、異常ではありません。
通知なしでソフトウェア処理へフォールバックする場合
Jellyfin は再生の継続を優先します。ハードウェア処理の経路を利用できない場合、ストリームを失敗させずにソフトウェア処理へ切り替えるため、実際の判断材料はエラーバナーではなく、CPU 負荷と FFmpeg のログです。
トランスコードログに Cannot load libnvcuvid.so.1 と表示される場合、デコーダーライブラリがコンテナにマウントされていません。NVIDIA_DRIVER_CAPABILITIES=all を設定してコンテナを再作成してください。環境変数の変更を反映するには docker compose up -d が必要で、通常の再起動では古い設定が保持されます。
h264_nvenc からの No capable devices found は、FFmpeg がエンコーダーライブラリに到達したものの、利用可能なカードを見つけられなかったことを示します。docker compose exec jellyfin nvidia-smi を再度確認してください。通常は、デバイスの予約が解除されたか、古いファイルからコンテナを再作成したことが原因です。
GPU がほとんど動作していないのに CPU 使用率が高い場合、デコード側がエラーを表示せずに失敗しています。使用している世代でデコードできないコーデックの選択を外し、同じファイルを再生して FFmpeg のログをもう一度確認します。-hwaccel cuda が表示されるかを確認してください。
トランスコードが開始した後、1080p では問題ないのに 4K HDR で停止する場合、インストールの破損ではなく、トーンマッピングの処理限界です。nvidia-smi dmon -s u の sm 列で確認し、クライアントが要求する解像度を下げるか、4K HDR ファイルをダイレクトプレイできるクライアントで再生してください。
FAQ
Jellyfin で NVENC を有効にしても CPU が使われ続けるのはなぜですか？
Dashboard、Logs の順に開き、最新の FFmpeg.Transcode ログを確認します。libx264 と表示される場合、ハードウェア経路はまったく使われていません。通常はコンテナから GPU が見えていないため、docker compose exec jellyfin nvidia-smi を実行して確認します。h264_nvenc と表示されるのに CPU 使用率が高い場合は、デコード側がソフトウェアで動作しています。これは、GPU がデコードできないコーデックを選択した場合や、Enable hardware encoding を無効のままにしてパイプラインの一部しか GPU に移していない場合に発生します。
Docker Compose に runtime: nvidia の行はまだ必要ですか？
deploy.resources.reservations.devices ブロックを使用しており、最新の Docker Compose を使っているなら必要ありません。このブロックは現在のデバイス要求形式で、同じ役割を果たします。runtime: nvidia は nvidia-docker2 時代の古い方式ですが、現在も動作します。Jellyfin 自身が公開している例でも両方が指定されています。両方を残しても問題ありません。runtime: nvidia だけを残す場合は NVIDIA_VISIBLE_DEVICES=all も残す必要があります。この方式にはデバイス要求がなく、環境変数からデバイス一覧を取得するためです。
1 台の NVIDIA GPU で同時にトランスコードできるストリーム数はいくつですか？
NVIDIA が公開している一覧では、2026 年 8 月時点で GeForce カードの同時エンコードセッション数は 12 に制限され、データセンター向けカードは無制限とされています。ただし、この上限が問題になることはほとんどありません。HDR から SDR へのトーンマッピングは NVENC ではなくシェーダーコアで実行されるため、4K HDR ストリームが数本あるだけで、セッション数の上限に達する前にシェーダーを使い切ることがあります。nvidia-smi dmon -s u で実際の環境を測定し、セッション数ではなく sm 列を監視してください。
GPU のない VPS でハードウェアトランスコードを使用できますか？
できません。エンコードには物理的な NVENC ブロックが必要です。標準的な VPS で lspci -nn | grep -Ei "3d|display|vga" を実行しても、ハイパーバイザーが提供する仮想ディスプレイアダプターしか表示されません。GPU のないプランで現実的なのは、トランスコード自体を減らすことです。クライアントの画質設定を Auto に上げ、ブラウザーではなくネイティブクライアントアプリを使用し、画像ベースの字幕トラックをテキストに変換して、ビデオの再エンコードを発生させないようにします。
1080p のトランスコードは正常なのに、4K HDR で再生が途切れるのはなぜですか？
2 つの処理では、GPU の異なる部分を使用します。1080p SDR のトランスコードはデコードとエンコードだけで、どちらも固定機能ハードウェア上で実行されます。4K HDR ストリームでは、シェーダーコア上で動作する CUDA フィルターであるトーンマッピングと、より大きなフレームのスケーリングが加わります。nvidia-smi dmon -s u で enc と dec が低い一方、sm が高く表示される場合は、この状況を確認できます。このパターンは、固定機能ブロックがアイドル状態で、汎用コアが処理の上限になっていることを示します。