Jellyfinはクライアントの制限をトランスコードパイプラインに変える

Jellyfinは、メディアに含まれる内容と、再生を要求するクライアントが受け入れられる内容との差分から、再生処理の経路を構築します。

その差分は、コンテナのリマックスだけで済むほど小さい場合もあれば、音声変換に限られる場合もあります。また、映像のデコード、フィルタリング、トーンマッピング、字幕の合成、再エンコードまで必要になるほど大きい場合もあります。この経路を理解すると、「同じファイル」でもサーバーの負荷が一律ではない理由が分かります。各クライアントの再生判断を記録し、一般的な「トランスコード」というラベルではなく、Jellyfinが実際に呼び出す処理段階に基づいて容量計画を行いましょう。

ダイレクト再生は変換なしの基準です

クライアントが元のコンテナ、映像、音声、字幕の経路を受け入れられる場合、サーバーは主にファイルを読み込んで配信します。この基準によって、メディア配信と変換処理の容量を切り分けられます。

クライアント側の音声処理によって、メディアファイルを変更せずに再生動作が変わることがあります。Android TVでのE-AC3ダイレクト出力では、ローカルPCMデコードによってダイレクト再生が維持されたケースがある一方、問題が発生しています。

ダイレクト再生が安定して行えるクライアントとファイルを1組確立してください。その実行結果を基準にして、トランスコードしたケースのCPU、GPU、ネットワークのグラフを比較します。

互換性の差が小さければ、リマックスまたは音声処理だけで済む場合があります

コンテナや音声形式が未対応でも、必ずしも映像変換が必要になるわけではありません。映像ストリームをそのまま維持できれば、サーバーの負荷を完全なトランスコードより大幅に抑えられます。

クライアント互換性の経路では、映像を変更せずに音声やコンテナの処理だけが変更される場合があります。

ダイレクト再生ではないセッションをすべて同じものとして扱う前に、ダッシュボードに表示される変換理由とFFmpegコマンドを確認してください。測定では、コピー、音声変換、映像エンコードを区別します。

映像の非互換性によって処理パイプラインは拡大します

映像自体を変更する必要が生じると、Jellyfinではデコード、フィルタリング、スケーリング、トーンマッピング、字幕の焼き込み、エンコードが必要になる場合があります。プラットフォームやメディアによっては、一部の処理をハードウェアで実行できる一方、他の処理はCPUに残ります。

リアルタイム出力はコーデックとフィルターの負荷によって変化するため、プロセッサーのモデルだけではJellyfinのトランスコード容量を予測できません。

対象ファイルを使い、エンジンごとのGPU使用率とCPU使用率を記録してください。ハードウェアアクセラレーション対応のストリーミング経路は、「GPUがアクティブ」という1つの表示から推測するのではなく、処理段階ごとに検証する必要があります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

再生の判断は容量の判断でもあります

サーバーのハードウェアが変わらなくても、クライアントの設定、字幕の選択、帯域幅の制限によって、ストリームがより負荷の高い経路に移行することがあります。そのため、容量計画には変換を引き起こすクライアントとポリシーを含める必要があります。

USEメソッドを使うと、トランスコーダーが常にCPU負荷になると決めつけず、飽和しているリソースに診断の焦点を合わせられます。

代表的なクライアント、メディア、字幕、リモート再生時の制限からなる小さなマトリクスを作成してください。結果として生じた再生モードを記録しておけば、将来のリグレッションを症状から推測するのではなく、変更された判断に結び付けて追跡できます。