Jellyfinのネイティブクライアントとブラウザクライアントで再生が異なる理由
Jellyfinの再生結果が異なるのは、ネイティブアプリとブラウザが、対応するコーデック、字幕、HDR、デコード、バッファリングの能力をそれぞれ異なる形で通知するためです。
同じファイルでも、テレビアプリではダイレクト再生できる一方、ブラウザではリマックスや完全なトランスコードが発生する場合があります。これにより、出力結果と関わるサーバーリソースの両方が変わります。メディア、ネットワーク、サーバーの条件を固定し、クライアントだけを切り替えて、観測された違いが機能の対応状況またはレンダリング動作によるものか確認してください。
機能のネゴシエーションで再生経路が決まる
Jellyfinは、ソースのコンテナ、映像、音声、HDRモード、字幕と、クライアントが受け入れられる形式を比較します。対応していない機能が1つでもあると、負荷の低い配信経路が追加の変換処理へと変わります。
再生品質を判断する前に、既知の1つのファイルを両方のクライアントで再生し、クライアント機能プロファイルのモードを記録してください。
そのため、「同じメディア」であることは、同じサーバー負荷になることを意味しません。
ブラウザの制限によってサーバー側の処理が増えることがある
ブラウザは、ネイティブアプリより狭い、または異なるメディア対応範囲を使用することがよくあります。対応していない音声、HDR、字幕、コンテナがあると、ブラウザ自体が高速に見えても、リマックスや映像トランスコードが必要になる場合があります。
実際のトランスコード負荷を比較すると、クライアントの対応状況によってサーバー側の処理経路が変わるタイミングを確認できます。
ブラウザでより重い経路が使用される場合、出力の違いは互換性によるものであり、サーバーが不可解な判断をしているわけではありません。
クライアント側のデコードも滑らかさを左右する
ネイティブデバイスではハードウェアデコードが使われる一方、ブラウザでは別のデコーダーやバッファ戦略が使われることがあります。これにより、サーバー側のスループットが変わらなくても、起動、シーク、フレーム落ち、バッテリー消費に影響が出ます。
Jellyfinクライアントの動作に関する記事では、コーデック対応、ハードウェアデコード、インターフェースの応答性を別々の指標として扱っています。
再生ベンチマークとUIベンチマークは分けて考えてください。ポスター一覧が高速でも、高ビットレートのストリームが滑らかに再生できるとは限りません。
既知のファイルでクライアントを比較する
同じネットワークとサーバー条件で、ネイティブアプリとブラウザから1つのファイルを再生します。再生モード、最初のフレームが表示されるまでの時間、安定時のバッファ、クライアント側のフレーム挙動を記録してください。
再生経路が判明してから、Jellyfinクライアントの動作に関するクライアント比較を使用してください。そうしないと、UIの遅延をストリーム配信の失敗と取り違える可能性があります。
クライアントの機能差によって出力とサーバーの指標を説明できた時点で調査を終えてください。クライアントだけのレンダリング制限に対して、サーバーハードウェアを調整しないでください。
おすすめ商品
テック＆AIハブ
もっと読む
ホームサーバーにサービスを追加すると、Home Assistantのアーキテクチャはなぜ変化するのか？
サービスを追加して共有状態、キュー、デバイス、更新サイクル、または障害ドメインが増えると、単にコンテナが増えるだけでなく、Home Assistantのアーキテクチャが変わります。
キャッシュを容量と取り違えずにHome Assistantのパフォーマンスを測定する方法
ウォーム状態での結果は、容量ではなく再利用を示します。コールドスタート、ウォーム時の定常状態、繰り返し負荷、テールレイテンシ、そして最初に飽和するリソースを測定してください。
Home Assistantで家全体を制御するには、どれくらいの自動化同時実行数が必要ですか？
家全体の自動化の多くは、重複実行数に上限を設けるだけで十分です。実行時間×トリガー発生率で同時実行数を見積もり、その後、下流システムが安全に処理できる容量を上限にします。
