JellyfinのパフォーマンスがLAN接続とリモート接続で異なる理由

Jellyfinのリモート再生時の動作が異なるのは、同じサーバーでも利用できるアップロード帯域が少なく、経路の変動が大きく、ルーティングが異なり、再生プロファイルも変わることが多いためです。

有線イーサネットに接続された4Kテレビでは高ビットレートのファイルをダイレクト再生できても、携帯電話では、リバースプロキシやVPN経由で上限を設定した1080pトランスコードが配信されることがあります。サーバーハードウェアは変わっていませんが、クライアント、利用可能なビットレート、遅延、セキュリティ経路が変わっています。こうした条件の変化によって処理内容が変わり、異なる障害発生箇所が生じます。

LANの帯域幅は通常、元の再生経路を維持する

有線LANは一般に、高速で安定したスループットと低遅延を提供するため、互換性のあるクライアントは品質を下げずに元のファイルを要求できます。ローカル検出とプライベートアドレスへの直接接続により、接続確立に必要な要素もいくつか省けます。

ダイレクト再生の目的は、既存のメディアを変更せずに送信することです。LANでは十分な帯域幅があるため、多くの家庭用回線のアップロード帯域を超えるようなソースビットレートでも、このモードを利用できます。

この利点は、混雑したWi-Fiやソースをデコードできないクライアントでは失われます。「ローカル」とはトポロジーを示すだけで、性能が保証されるわけではありません。そのため、電波の弱い無線区間が最も遅い段階になることもあります。

リモートのアップロード帯域とビットレート設定が変換を引き起こす

リモートトラフィックはサーバー設置場所のアップロード回線を通過します。この回線は、ダウンロード回線やLANよりもはるかに遅いことがよくあります。Jellyfinまたはクライアントが低いビットレートを選択すると、リモートデバイスが元のコーデックに対応していても、映像変換が必要になる場合があります。

同時ストリーム数とアップロード速度を使った容量モデルを見ると、リモートセッションが1つ増えるごとに、共有アップストリーム帯域が消費される理由が分かります。ソースビットレートのピークには、単純な平均値以上の余裕が必要です。

その結果、需要が相互に影響します。ネットワークビットレートを下げればアップロード帯域は節約できますが、サーバーの計算資源を消費します。ローカル再生中はアイドル状態のGPUが、リモートユーザーの接続時だけ高負荷になることもあります。

インターネットのルーティングは遅延、パケットロス、中継要素を加える

リモートセッションでは、ISPのルーティング、NAT、TLS終端、リバースプロキシ、メッシュVPN、リレーなどを経由することがあります。それぞれの要素が、2つのLANアドレス間には存在しないバッファリング、タイムアウト、ヘッダー制限、帯域幅制約を追加する可能性があります。

LANではスムーズだがリモートではバッファリングするという報告は、ネットワークやプロキシ経路が変わると、同じメディアとサーバーハードウェアでも結果が異なることを示しています。この症状だけでは、どの中継要素が原因かは特定できません。

遅延の増加は、起動時、シーク時、パケットロスからの復旧時に最も目立ちます。安定再生中は十分なバッファリングによって遅延を隠せますが、スループットが不足していれば、無期限に補うことはできません。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

LANとリモートを比較する手順

テスト間でクライアント、要求品質、字幕トラック、再生モードが変わると、比較は無効になります。ネットワークについて結論を出す前に、リモートとLANの結果でこれらの変数を一定に保つ必要があります。

エンドツーエンドの再生経路を使って、ストレージ、変換、配信を個別に分類します。そのうえで、OSとネットワークの測定結果と併せて、ダッシュボードの再生モードを確認します。別の現地レポートでも、目に見える症状だけでボトルネックを判断せず、LANとリモートの比較を行うことが推奨されています。

同じデバイスとファイルを使い、ローカル、元の品質でのリモート、固定した低ビットレートでのリモートをテストします。再生モード、トランスコード速度、アップロード速度、遅延、パケットロス、起動時間、再バッファリングの発生回数を記録します。障害発生時に最初に変化した変数が、次に調査すべき層を示します。