リモートユーザーや低速なアップロード環境に適した Jellyfin ハードウェアの選び方

低速なアップロード回線でリモートからJellyfinを利用する場合、最初に確認すべきハードウェアの問題は「CPUコア数はいくつか」ではありません。「家庭内の他の通信に余裕を残したうえで、ホーム回線が安定して継続的に提供できるビットレートはいくつか」です。そのうえで、ハードウェアは、互換性のないストリームやサイズの大きいストリームを、リアルタイムでそのネットワーク帯域に収まる形へ変換できなければなりません。

これは、よくある購入時の誤りを覆す考え方です。非常に高性能なサーバーでも、変換なしに60 Mbpsのリマックスを安定した15 Mbpsの上り回線で送信することはできません。また、インターネット回線自体に十分な余裕があっても、メディアエンジンが非力ならリモート再生に失敗することがあります。

サーバーを選ぶ前にアップロード速度を測定する

リモート視聴が行われそうな時間帯に、家庭内の回線をテストしてください。ISPが公称するプラン速度ではなく、継続的なアップロード速度を測定し、ビデオ通話、バックアップ、カメラ、通常のウェブ閲覧に使う帯域も確保します。

Jellyfinの現在のハードウェアガイドでは、リモートアクセスには少なくとも20 Mbpsのアップロード速度を推奨しており、回線速度が100 Mbps未満の場合は、Jellyfinのインターネットストリーミング制限をアップロード速度のおよそ70%に設定することを提案しています。これは計画を立てる際の出発点であり、すべての家庭での結果を保証するものではありません。

ZimaSpaceによる複数ユーザー利用時のJellyfinの帯域幅に関する分析は、その回線予算を同時利用するリモートストリームのシナリオに置き換えるのに役立ちます。

実際に必要な変換に合わせてメディアエンジンを選ぶ

アップロード速度が遅いと、ビットレートを下げる必要が生じることが多く、高ビットレートのソースメディアでは動画のトランスコードが必要になります。CPUの内蔵グラフィックスまたはディスクリートGPUが、ソースコーデックと出力形式に対応しているか確認してください。

リモート変換が必要になるかどうかは、クライアントが受け入れられる形式と、サーバーが配信しなければならないビットレートによって決まります。Jellyfinの現在のトランスコードモデルは、クライアントのコーデック、解像度、ビットレートの制約をもとに、メディアを変換する必要があるか判断します。リモート変換を頻繁に行うなら、使用するソース形式と出力形式に対して検証済みのメディアエンジンを備えたハードウェアを選びましょう。

HEVC 10-bit、HDRトーンマッピング、AV1、字幕の挙動はそれぞれ個別に確認してください。デコードはアクセラレーションできても、必要なエンコードやトーンマッピングの処理を高速化できないメディアエンジンでは、CPUによる高負荷な処理に戻る可能性があります。

アップロード回線で活用できないほどのトランスコード性能を買わない

家庭の上り回線が持続的に20 Mbpsで、他の通信のために6 Mbpsを確保する場合、GPUのサイズにかかわらず、同時に4本の8 Mbpsリモートストリームを収めることはできません。ネットワークの上限は、1ストリームあたりの制限を下げる、同時セッション数を減らす、またはより高速なインターネットプランに変更することで解決する必要があります。

一方、1本の4Kソースを6 Mbpsの1080pストリームに変換する必要がある場合、サーバーにはそのストリームをリアルタイムより速く生成できるだけのアクセラレーションが必要です。ハードウェアとネットワークは直列に存在する2つの制約であり、結果を決めるのは小さい方の制約です。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

トランスコード用スクラッチ領域を隠れた制限要因にしない

トランスコードでは一時セグメントが書き込まれます。複数のリモートセッションを同時に変換すると、メディアエンジンに余力があっても、小容量または低速なスクラッチ領域がボトルネックになる可能性があります。

トランスコードでは一時セグメントが継続的に書き込まれるため、想定される最大同時変換時間に対応できるだけの空き容量と書き込み性能をスクラッチ領域に確保してください。

SSDや十分な容量のRAMベースのスクラッチ領域を使う場合は、容量を計画したうえで導入してください。一時的なトランスコードファイルによって、Jellyfinのデータベースやメタデータも保存されている小さなシステムディスクを満杯にしないようにしましょう。

インターネット速度テストではなく、通常時に想定される最悪のリモート経路に合わせて購入する

実際のリモートワークロードを余裕を持って処理できる、最小限のサーバーを選びましょう。アップロード速度を改善すれば、一部のビットレート変換が不要になる場合があります。メディアエンジンを改善すれば、低速なアップロード回線でも利用しやすくなります。ただし、どちらのアップグレードももう一方の代わりにはなりません。

よくある質問

低速なアップロードが原因のJellyfinのバッファリングは、高速なCPUで解決できますか？

CPUまたはメディアエンジンが十分な速度でトランスコードできていない場合に限り、解決できる可能性があります。最終的なストリームが利用可能なアップロード帯域幅を超えている場合、計算能力を増やしてもネットワークのボトルネックは解消できません。

Jellyfinのリモートビットレートは、ISPのアップロード速度いっぱいに設定すべきですか？

通常はおすすめしません。他の家庭内通信や通常の速度変動に備えて余裕を残してください。まず継続的なアップロード速度を測定し、そのうえで保守的なリモート通信の合計予算を設定します。