なぜホームサーバーでJellyfinがバッファリングするのですか？

Jellyfinは再生経路のいずれかがタイムラインの進行より速くビデオを配信、変換、またはデコードできない場合にバッファリングします。ビデオトランスコードが一般的な原因ですが、それだけではありません。クライアントのコーデック制限、字幕処理、不安定なWi-Fi、リモートのアップロード帯域不足、ストレージの競合、または一時データを受け入れられないトランスコードディレクトリが原因でストリームが停止することもあります。

ボトルネックを見つける最速の方法は、ハードウェア設定を変更する前に現在の再生モードを確認することです。その後、問題がすべてのファイルに影響するのか、4KやHDRメディアだけなのか、特定のクライアント、リモートユーザー、字幕付き再生、または複数の同時ストリームに影響するのかを比較します。

何かを変更する前に再生モードを確認する

影響を受けているビデオを再生中にJellyfinダッシュボードを開き、アクティブセッションを確認します。これにより、サーバーが元のファイルを配信しているのか、一部を積極的に変換しているのかがわかります。

Jellyfinは再生を4つの再生経路に分けており、サーバー負荷は段階的に高くなります：Direct Play、Remux、Direct Stream、ビデオトランスコードです。Direct Playはほぼ処理なしで元のメディアを送信し、Remuxはコンテナを変更し、Direct Streamはビデオを保持しつつオーディオを変換し、Transcodeはビデオストリームを再エンコードします。

この最初の結果がトラブルシューティングの方向性を大きく変えます。Direct Playでバッファリングが発生する場合は、ネットワーク、ストレージ、クライアント、メディアファイルから調査を始めてください。ビデオトランスコードでバッファリングが発生する場合は、変換が要求された理由とサーバーがパイプライン全体を十分に速く完了できるかを確認してください。

Jellyfinがトランスコードを要求した理由を確認する

クライアントがビデオコーデックをサポートしているだけでは、ファイルがDirect Playされるわけではありません。Jellyfinはコンテナ、ビデオコーデック、コーデックプロファイル、ビット深度、解像度、オーディオフォーマット、チャンネルレイアウト、字幕、ビットレート、クライアントの再生制約の全組み合わせを評価します。

例えば、クライアントはHEVCビデオをサポートしていても、含まれるTrueHD音声トラックをサポートしていない場合があります。別のクライアントは両方のストリームをデコードできても、選択された字幕形式のレンダリングに失敗することがあります。これらの違いにより、同じファイルがあるデバイスではDirect Play、別のデバイスでは音声変換、ブラウザでは完全なビデオトランスコードになることがあります。

設定を変更する前に再生理由を記録してください。また、別の音声トラックをテストし、字幕を無効にし、別のJellyfinクライアントで同じファイルを再生してください。これらの制御されたテストは、トランスコードメニューのすべてのコーデックボックスを有効にするよりも有用です。

ソフトウェアトランスコードは小型サーバーに過負荷をかけることがあります

ソフトウェアトランスコードはCPUを使ってソースをデコードし、フィルターを適用し、画像をスケーリングし、新しいストリームをリアルタイムでエンコードします。低性能のプロセッサは1080pの変換は処理できても、4K HEVC、10ビット映像、HDRのソースでは失敗することがあります。

変換が再生に追いつかない場合、クライアントはバッファされたビデオセグメントを消費し、再生を一時停止します。Jellyfinが現在の位置より先のデータを繰り返し構築しようとするため、CPU使用率は最大近くで推移することがあります。

サーバーに対応する統合または専用GPUがあり、ハードウェアアクセラレーションが正しく設定されていれば、通常はFFmpegのスレッド数を変更するよりも効果的です。対応するエンコーダーがない場合は、要求する解像度やビットレートを下げて、トランスコード能力が制限要因かどうかを確認できます。

ハードウェアアクセラレーションは多段階のパイプラインです

ダッシュボードでIntel Quick Sync、VA-API、NVIDIA NVENC、AMD AMFを選択しても、変換のすべての部分がGPUで実行される保証はありません。

Jellyfinのトランスコードには、デコード、インターレース解除、スケーリング、フォーマット変換、HDRトーンマッピング、字幕の焼き込み、エンコードが含まれます。Jellyfinはハードウェア、ドライバー、ソフトウェアの制限により一部の段階がCPU上で実行される場合があると注意しています。部分的なアクセラレーションは、GPUの動作が見えていても高いCPU使用率を引き起こすことがあります。

GPUの有無だけでなく、ジョブ全体を確認してください。予測可能なトランスコードを強制し、ビデオのデコードおよびエンコードエンジンを監視し、FFmpegコマンドを検査し、ソフトウェアにフォールバックしたフィルターを探してください。

GPUが対応していないデコード形式を有効にしないでください

ハードウェアアクセラレーションのページでは、管理者がJellyfinがGPUを通じてデコードを試みるビデオフォーマットを選択できます。サポートされていないフォーマットを有効にしても、その機能がハードウェアに追加されるわけではありません。

GPUが正確なコーデックプロファイルやビット深度をデコードできない場合、Jellyfinはソフトウェアデコードにフォールバックするか、ハードウェアパスの初期化に失敗することがあります。これが、あるHEVCファイルは動作するのに別のファイルで予想外に高いCPU使用率が発生する理由です。

GPUの世代と対応プロファイルを確認し、実際に処理可能なフォーマットのみを有効にしてください。すべての4Kメディアを一括で扱うのではなく、通常のH.264、HEVC Main 10、HDRファイルを個別にテストしてください。4k-home-media-server

DockerにGPUへのアクセス権を与える必要があります

ホストOSで検出されたGPUは、自動的にJellyfinコンテナ内で利用可能になるわけではありません。コンテナには正しいデバイスマッピング、ランタイム、ドライバー、グループ、および権限が必要です。

Linux上のIntelおよびAMD GPUでは、ホストが通常/dev/driの下にレンダーデバイスを公開します。コンテナユーザーは関連するレンダーデバイスにアクセスできる必要があります。NVIDIAの設定にはホストドライバーと適切なコンテナランタイムが必要です。実用的なDockerのチェックには、レンダーデバイスの確認、コンテナへのマッピング、正しいレンダーグループGIDの追加が含まれます。

コンテナを特権モードのままにしておくのは恒久的な解決策ではありません。デバイスアクセスの問題を確認するために一時的に使用できますが、最終的な展開では必要なGPUリソースと権限のみを公開するべきです。

実際のトランスコード中のGPUアクティビティを確認する

コンテナの起動が成功しても、ハードウェアトランスコーディングが機能しているとは限りません。Jellyfinは正常に動作し、ライブラリをスキャンし、Direct Playファイルを再生できますが、GPUへの実用的なアクセスがない場合もあります。

ソースよりも低いクライアント品質を一時的に選択してトランスコードを強制します。Intelシステムでは、次のようなツールでビデオエンジンを監視します。 intel_gpu_topNVIDIAシステムでは、アクティブなプロセスとエンコーダーのアクティビティを次のコマンドで確認します。 nvidia-smiまた、ソフトウェアトランスコーディングと比較してCPU使用率が低下しているかどうかも確認してください。

GPUのアクティビティがない場合は、マッピングされたデバイス、コンテナユーザー、レンダーグループのメンバーシップ、ハードウェアアクセラレーションの方法、およびFFmpegのログを確認してください。GPUがアクティブで再生が遅いままの場合、別のパイプライン段階がソフトウェアで実行されている可能性があります。

字幕は完全な動画トランスコードを引き起こすことがあります

よくある症状は、字幕を有効にするまでスムーズに再生されることです。これは画像ベースの字幕や、選択されたクライアントが直接レンダリングできないスタイル付きフォーマットでよく起こります。

Jellyfinが字幕を映像に焼き込む必要がある場合、すべてのフレームをデコードし、字幕レイヤーをレンダリングし、新しい動画ストリームをエンコードします。これにより、通常は負荷の低いDirect Playセッションがサーバーで最も負荷の高い再生経路の一つに変わることがあります。

字幕を無効にして同じシーンを再生してください。バッファリングが消えたら、SRTのようなテキストベースの字幕トラックを試すか、別のクライアントをテストするか、選択されたハードウェア経路が周辺のデコード、フィルタリング、エンコード処理を加速できるか確認してください。

HDRトーンマッピングは通常のトランスコードより負荷が高いことがあります

1080pや通常の4K SDRメディアは正常に再生されるのに、SDRクライアントでHDRコンテンツがバッファリングする場合、トーンマッピングが有力な原因です。

サーバーは10ビットHDRソースをデコードし、色と輝度範囲をSDRに変換し、スケーリングし、新しい動画ストリームをエンコードする必要があります。通常のH.264トランスコードが可能なシステムでも、ソフトウェアでリアルタイムにこの全作業を行うのは難しい場合があります。

同じHDRファイルをHDR対応クライアントでテストし、その後SDRトランスコードを強制してCPUとGPUの動作を比較してください。HEVCデコードのハードウェアサポートがあっても、選択されたトーンマッピング方式が完全にアクセラレーションされているとは限りません。

クライアントが再生経路の多くを決定します

JellyfinはデスクトップメディアクライアントではDirect Playを行いながら、ブラウザやテレビアプリケーションではトランスコードすることがあります。この違いはセッション間でサーバー設定が変わったことを意味しません。

各クライアントは対応可能なコーデック、コンテナ、音声フォーマット、字幕、解像度、ビットレート制限を報告します。より高性能なプレーヤーは変換を回避できますが、制限のあるプレーヤーは音声変換、リマックス、または完全な動画トランスコードが必要になる場合があります。

同じファイル、音声トラック、字幕トラック、ネットワーク接続を2つのクライアントでテストしてください。問題が特定のクライアントにのみ発生する場合は、サーバーを変更する前にそのデバイスの再生能力とアプリ設定を調査してください。

Direct Playでもバッファリングが発生することがあります

Direct Playは動画変換を主なボトルネックから解放しますが、経路の他の部分が正常であることを保証するものではありません。

NASはメディアを読み込み続け、ネットワークはそれを途切れなく配信し、クライアントはそれをデコードしてレンダリングしなければなりません。高ビットレートのピーク、不安定なWi-Fi、遅いクライアントインターフェース、ストレージのエラー再試行、または性能不足のプレーヤーが、直接ストリームを妨げることがあります。

問題のファイルをクライアントにコピーしてローカルで再生します。ローカル再生でもスタッターが発生する場合は、メディアファイルかクライアントのデコーダーを調査してください。ローカルコピーが正常に動作し、JellyfinのDirect Playでバッファリングが起きる場合は、ネットワークとサーバーストレージ経路に注目してください。

インターネット速度テストではなく、実際のLAN経路をテストしてください

高速なインターネット速度の結果は、Jellyfinサーバーから家庭内のテレビ、電話、ストリーミングボックスへの経路を測定しません。また、Wi-Fiのジッター、パケットロス、メッシュバックホールの混雑、遅いデバイスインターフェースも明らかにしません。

有用なローカル診断は、持続的なファイルコピーのスループット、有線クライアント、低ビットレートのエンコード、元の高ビットレートファイルを比較します。実用的なローカルストリーミングのチェックにはイーサネットのテスト、クライアントがトランスコードを強制しているかの確認、視聴時間外に重いバックグラウンドタスクを移動することも含まれます。

数秒間だけ表示される最高値ではなく、持続的なパフォーマンスを確認してください。大きなビットレートのピークがある動画は、短時間のネットワーク遅延を乗り切り、クライアントのバッファを枯渇させないだけの余裕が必要です。

リモートバッファリングは通常、別の原因があります

同じメディアが自宅で正常に再生されるのに外部接続でバッファリングする場合、サーバーのアップロード帯域幅とリモートルートが主な疑いとなります。

使用可能な速度は、家庭のアップロード速度、リモートクライアントのダウンロード速度、VPNやリバースプロキシのオーバーヘッド、家庭内の競合トラフィック、ストリームのビットレートによって制限されます。大きなリマックスは、LAN上で完璧にDirect Playできても、利用可能なアップロード容量を超えることがあります。

リモート再生の品質を一時的に下げてみてください。それでバッファリングが解消される場合は、持続可能なリモートビットレートを設定するか、ハードウェアトランスコーディングを使って小さいストリームを作成します。低い設定は帯域幅の制限を示す証拠とし、元のファイルが壊れている証明とは見なさないでください。

同時作業下ではストレージの故障リスクが高まります

正常なハードドライブは通常、普通の映画ストリームを問題なく再生できます。再生がダウンロード、バックアップ、ライブラリスキャン、サムネイル生成、パリティ操作、スクラブ、または複数ユーザーと重なると、ストレージの問題が疑われます。

これらのタスクは読み取り、書き込み、シークが競合します。ディスクはベンチマークで許容できる連続速度を示していても、混合したアクティビティ下で高いレイテンシを発生させることがあります。

バッファリングが発生している間、利用率と遅延を監視してください。ダウンロードやメンテナンスジョブを一時停止し、同じファイルを再生してみてください。Jellyfinのデータベース、メタデータ、キャッシュは可能な限り低遅延のストレージに置き、大きなメディアファイルは容量重視のディスクに置くことをおすすめします。

トランスコードディレクトリの容量不足は再生停止を引き起こす

トランスコードされたビデオはクライアントが消費する前に一時的なセグメントとして書き込まれます。割り当てられたファイルシステム、SSD、RAMディスク、またはDockerボリュームに十分な空き容量がないと、FFmpegは新しいセグメントを生成できなくなります。

以前のJellyfinの問題では、トランスコードディレクトリが満杯になるまで作成された最後のセグメントまでしか再生が続かないことが記録されています。この報告は古くクローズされていますが、トランスコードされたストリームが数分後に停止する場合、空き容量を調べる有用な理由となります。

トランスコードパスの空き容量、inodeの利用可能性、コンテナマッピング、書き込み権限、容量制限を確認してください。特に小さなRAMディスクや一時ファイルシステムには注意が必要です。メモリを使うことでストレージの遅延は減りますが、容量制限が小さいと突然の再生失敗を引き起こすことがあります。

1つの問題ファイルは通常メディアに原因がある

解像度とビットレートが似ている多くのファイルが正常に再生される場合、1つの問題のあるタイトルだけでサーバー全体が性能不足だと証明する可能性は低いです。

ファイルには異常なコーデックプロファイル、破損したフレーム、サポートされていないオーディオレイアウト、画像字幕トラック、誤ったタイムスタンプ、または極端なビットレートのピークが含まれている可能性があります。あるシーズンだけが他と異なるエンコードであることもあります。

別のオーディオトラックを試し、字幕を無効にし、メディア情報を確認し、同じコーデックを使った別のタイトルとファイルを比較してください。新しいコンテナへの単純なリマックスは、ビデオ全体を再エンコードせずにコンテナやタイムスタンプが関係しているかどうかを判断するのに役立ちます。

複数のストリームは共有リソースの限界を明らかにする

ホームサーバーは1つのストリームを完璧に処理し、別のユーザーが再生を開始したときにのみバッファリングを始めることがあります。ネットワークだけが原因だと決めつける前に、すべてのアクティブセッションの再生モードを比較してください。

複数のDirect Playセッションは主にストレージとネットワークの負荷を増加させます。複数のビデオトランスコードはGPUエンコード能力、CPUフィルター、メモリ帯域幅、トランスコードディレクトリの容量を競合します。

1つのセッションをテストし、CPU、GPU、ディスク、ネットワークの使用状況を見ながらストリームを1つずつ追加します。これにより、実際の制限が変換数、総メディアビットレート、または混合ストレージ活動のどれであるかを特定できます。

Jellyfinを再インストールする前にFFmpegログを読みます。

サーバーダッシュボードはどのタイプの再生が行われているかを示し、対応するFFmpegログはJellyfinがファイルをどのように処理しようとしたかを説明します。

ハードウェアデバイスの初期化失敗、権限エラー、サポートされていないプロファイル、ソフトウェアフォールバック、字幕フィルター、トーンマッピングフィルター、入出力エラー、プロセス終了コード、およびストレージ空き容量エラーを探します。

バッファリングしている正確なセッションのログを取得します。無関係なダイレクトプレイや成功したトランスコードのログは誤った結論を導くことがあります。サーバーの再インストールは、クライアントのコーデック制限、アクセスできないGPUデバイス、または一杯の一時ディレクトリを修正することはほとんどありません。

症状を使って次のテストを選択します。

このトラブルシューティング手順に従ってください。

1. 同じファイルとクライアントで問題を再現します。
2. Jellyfinダッシュボードを開き、再生モードを記録します。
3. 指定されたトランスコードまたは互換性の理由を記録します。
4. 字幕を無効にし、別の音声トラックをテストします。
5. 別のクライアントで同じファイルを再生します。
6. 影響を受けたセッション中のCPUおよびGPUの活動を確認します。
7. 該当するFFmpegログを開きます。
8. トランスコードディレクトリの空き容量と書き込み権限を確認します。
9. 持続的なLANスループットまたはリモートアップロード容量をテストします。
10. ダウンロード、バックアップ、スキャン、およびストレージメンテナンスを一時停止します。
11. 問題のファイルを類似のメディアと比較します。
12. 証拠が計算能力の限界を示した場合にのみ、新しいハードウェアの導入を検討してください。

この順序は、無関係な変更が元の原因を隠すのを防ぎます。変数は一度に一つずつ変更し、同じシーンを再生して結果を比較可能に保ってください。

最終的な結論

Jellyfinのバッファリングは必ずしもホームサーバーのCPUを高速化する必要があることを意味しません。まずはアクティブな再生モードから始めてください。Direct Playと動画トランスコードはシステムの異なる部分を指しています。

トランスコードされたセッションでは、変換が必要な理由を特定し、完全なハードウェアアクセラレーションパイプラインを検証し、字幕なしでテストし、HDRトーンマッピングを調査し、トランスコードパスに十分な書き込み可能スペースがあることを確認してください。Dockerでは、ホストの検出に頼らずコンテナ内からGPUを確認してください。

Direct Playの場合は、持続的なネットワークスループット、クライアントのデコード、ストレージの動作、個々のメディアファイルに注目してください。再生モード、クライアント、コーデック、字幕、リソースの動作、FFmpegログの組み合わせが、ランダムな設定変更やハードウェア交換よりも信頼できる診断を提供します。

よくある質問

なぜJellyfinは字幕が有効なときだけバッファリングするのですか？

選択された字幕フォーマットは焼き込みが必要な場合があります。その場合、Jellyfinは動画をデコードし、字幕をすべてのフレームにレンダリングし、新しいストリームをエンコードします。字幕を無効にするか、テキストベースのトラックを選択するか、字幕フォーマットを直接レンダリングできるクライアントを使用してみてください。

なぜJellyfinはあるデバイスではトランスコードし、別のデバイスではDirect Playするのですか？

クライアントはコンテナ、動画コーデック、音声フォーマット、字幕タイプ、プロファイル、ビットレートの異なる組み合わせをサポートしています。互換性の低いデバイスは、サーバーにファイルの未対応部分を変換するよう要求します。

Jellyfinのハードウェアアクセラレーションが動作しているかどうかはどう確認できますか？

動画のトランスコードを強制し、サーバーのGPUデコードおよびエンコードエンジンを確認してください。また、FFmpegのログが期待されるハードウェアデバイスを使用しているか、コンテナが権限エラーなしにデバイスにアクセスできるかも確認してください。

なぜJellyfinはDirect Playと言っているのにバッファリングするのですか？

Direct Playは動画のトランスコードを経路から除外しますが、ネットワーク、ストレージ、メディアファイル、クライアントのデコーダーが遅すぎたり不安定だったりすることがあります。同じクライアントでファイルをローカルにテストし、有線と無線の再生を比較してください。

JellyfinはトランスコードにSSDを使うべきですか？

SSDは一時セグメントの遅延を減らすことができ、Jellyfinのデータベース、メタデータ、キャッシュに役立ちます。より重要な要件は、十分なスペース、信頼できる書き込み、正しい権限を持つトランスコードパスです。適切なサイズのRAMディスクも機能しますが、サイズが小さすぎると再生が停止することがあります。