ネットワーク遅延が字幕付きJellyfin HDR再生に与える影響

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Network Latency Affects Jellyfin HDR Playback With Subtitles

ネットワーク遅延は、セグメントの配信と復旧を遅らせ、すでに複雑な変換処理がクライアントのバッファーと競合することで、JellyfinのHDR字幕再生に間接的な影響を与えます。

リモートクライアントは映画の再生に十分な平均帯域幅があっても、画像字幕によってビデオトランスコードが発生し、生成されたセグメント間にネットワークジッターが加わると、一時停止することがあります。HDRはソースと処理の負荷を高め、字幕の焼き込みによってDirect Playが利用できなくなる場合があります。プレーヤーのバッファー時間が、ネットワーク変動と通常より遅いフレームの両方を吸収するには少なすぎると、遅延が問題になります。

遅延が変えるのは公称ビットレートではなく復旧時間

20 Mbpsのストリームでは、往復時間が短くても長くても、継続的なペイロードとしておよそ20 Mbpsが必要です。遅延が重要なのは、確認応答、リクエスト、接続の確立、損失からの復旧に時間がかかり、次の有効なバイトがプレーヤーに届くまで遅れるためです。

アップロード速度を配信ビットレートで割る方法に基づく帯域幅計画は、必要容量の下限を示しますが、ジッターやバースト時のピークは捉えられません。必要なバッファー余裕を決めるのは、こうした時間軸上の影響です。

したがって、帯域幅が大きくても遅延が不安定な経路は、帯域幅がやや小さくても安定した経路より性能が悪くなることがあります。プレーヤーが直面するのは、月間や数分間の平均スループットではなく、配信の締め切りです。

字幕の焼き込みはネットワークをトランスコードのタイミングに結び付ける

字幕をHDRフレームに描画する必要がある場合、Jellyfinはデコード、合成、必要に応じたトーンマッピング、エンコードが完了するまでセグメントを配信できません。ネットワーク遅延は単純なファイル読み込みの後ではなく、変動する生成処理の後に始まります。

トランスコード中の字幕タイミングに関する報告からは、字幕の選択によって連続性や同期の挙動が変わることが分かります。目に見える症状はネットワーク関連に見えても、最初の遅延は送信前に発生している可能性があります。

この2つの遅延は、互いに置き換わるのではなく加算されます。高速なトランスコードはより大きなジッターに耐えられ、安定したネットワークは時折遅いセグメントにも対応できますが、両方の段階で余裕が乏しいとバッファーは急速に空になります。

HDRは締め切りに間に合わなかった場合の負担を増やす

HDRソースは高ビットレートであることが多く、クライアント互換性を狭めるコーデック、プロファイル、またはビット深度を使用している場合があります。経路がDirect Playから変換に切り替わると、より大きなフレームとトーンマッピングによって、各セグメントの締め切りまでに完了させる処理量が増えます。

HDRと字幕の変換に関する実践ガイドでは、対応ハードウェア、トーンマッピング、字幕形式、リモートビットレートを1つのつながった経路として扱っています。インターネット接続だけを最適化しても、サーバー側の処理タイミングは変わりません。

十分なバッファーがあり、安定したストリームであれば、遅延は必ずしも悪影響を及ぼしません。遅延が決定的になるのは、起動時、シーク時、パケット損失時、ビットレート変更時、またはバッファーを急速に補充する必要がある場面です。

Featured

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

ZimaCube2

制御されたテストで遅延とスループットを切り分ける

クライアント自体が配信された形式をデコードできない場合や、サーバーがリアルタイムを上回る速度でトランスコードできない場合、この主張は当てはまりません。こうした問題は、遅延ゼロのLAN上でも解消しません。同様に、アップロード帯域幅の不足は容量の問題であり、主に遅延の問題ではありません。

Jellyfinのバッファリング分析にあるエンドツーエンドの障害分類を使い、変数を一定に保ちます。同じクライアントとタイトルを使用し、配信品質と字幕の選択を同一にしたうえで、LANとリモートネットワークを比較します。別の実地報告でも、目に見える症状からボトルネックを決めつけるのではなく、制御されたネットワーク比較を行うことが支持されています。

起動時間、シークからの復旧、トランスコード速度、配信ビットレート、パケット損失、ジッター、バッファー時間を記録します。リモートでの遅延が増加してもトランスコード速度がリアルタイムを安全に上回っているなら、配信とバッファリングを調整します。両方が悪化しているなら、遅延だけを原因と考える前に変換コストを下げます。