クライアントの互換性とトランスコード性能：バッファリングを先に防ぐのはどちら？

1台または数台の再生デバイスがライブラリ内の動画、音声、コンテナ、字幕形式をDirect Playできないためにバッファリングが始まる場合は、追加のトランスコード性能を購入する前にクライアントの互換性を改善します。多くのクライアントで変換が避けられない場合、リモートのビットレート制限によって低品質のストリームが定期的に必要になる場合、または既存のトランスコードエンジンがリアルタイム処理に追いつかない場合は、まずサーバーのトランスコード能力を強化します。ネットワークが実際に配信されるビットレートを維持できない場合は、どちらのアップグレードも最初に行うべきではありません。

これは一般的な「クライアント対サーバー」の勝負ではなく、アップグレードの順序を決める判断です。最初に行うべきことは、実際の再生経路と、それが変わった理由を特定することです。互換性のあるクライアントなら、サーバーの処理を完全になくせます。一方、より高速なサーバーは、依然として必要な処理を速くするだけです。

まず、ストリームがDirect Playにならない理由を特定する

問題のあるストリームを1つ再生し、メディアサーバーの再生情報を確認します。Direct Play、Direct Streamまたはリマックス、音声のみのトランスコード、動画のトランスコードのいずれかに分類します。次に、理由を記録します。対応していないコーデック、対応していないコンテナ、字幕の焼き付け、ビットレート制限、HDRのトーンマッピング、またはその他のクライアント能力の制約です。

Plexでは、Direct Playを互換性のあるメディアを変換せずに送信すること、Direct Streamを互換性のあるストリームを再パッケージ化すること、トランスコードをクライアント向けにメディアを変換することと説明しています。ストリーミング経路の概要では、字幕によって、それ以外は互換性のある再生経路が変わる場合があることも説明されています。

この分類が安定するまでは、何も購入しないでください。ストリームがすでにDirect Playで、それでもバッファリングが発生する場合、クライアントのコーデック対応は最初に疑うべき問題ではなく、追加のトランスコード性能も使われない可能性があります。代わりに、ネットワークのスループット、Wi-Fiの品質、サーバーのディスク読み取り、実際に配信されているビットレートを確認します。

1. ストリームがDirect Playになる場合は、互換性とトランスコードの比較をやめ、配信経路を調査します。
2. 形式のサポートが原因で1台のクライアントが変換を強制する場合は、より互換性の高いクライアントまたはクライアントアプリを試します。
3. 多くのクライアントで変換が必要になる場合は、サーバーのトランスコード能力を測定します。
4. リモート帯域幅によってビットレートを下げざるを得ない場合は、サーバーでの変換能力とアップロード容量を別々の制約として扱います。

互換性がきっかけなら、より優れたクライアントが有効です。

ライブラリをネイティブにデコードできるクライアントなら、CPU や GPU に大きな負荷がかかるビデオトランスコードを Direct Play に切り替えられます。これは質的な変化です。サーバーは、そのエンドポイントに合わせるためだけにビデオをデコードして再エンコードする必要がなくなります。そのため、問題のあるテレビやストリーミングスティックが1台ある場合は、サーバーの計算能力を追加するよりも、エンドポイントを変更したほうが大きな効果を得られることがあります。

Jellyfin の最新のクライアントコーデック対応表を見ると、ブラウザー、Android TV、iOS、Roku、Kodi、デスクトップクライアント、コンテナ、オーディオ形式、HDR モード、字幕によって互換性が異なることが分かります。ライブラリ全体としては「標準的」でも、特定のエンドポイントの制限に直面することがあります。

条件が逆転するのは、利用端末の数が多い場合です。大半のトランスコードを引き起こしているエンドポイントが1台だけなら、そのクライアントを交換または変更するのは魅力的です。しかし、5人のリモートユーザー、複数の古いテレビ、モバイルデバイスがそれぞれ異なる変換を必要とする場合、互換性の問題をエンドポイントごとに解決するよりも、サーバーに十分な集中変換能力を持たせるほうが、運用コストを抑えられることがあります。

配信がボトルネックなら、どちらのアップグレードも効果がない

再生形式に完全な互換性があり、サーバーのトランスコード容量に余裕がある場合でも、バッファリングは発生することがあります。低速な Wi‑Fi 上の高ビットレートファイル、帯域が制限された WAN のアップロード、または混雑したクライアント側のリンクによって、コンピューティンググラフがすべて正常に見えても再生に必要なデータが不足することがあります。

Android のメディアドキュメントにはプラットフォームのデコード機能とコンテナのサポートが記載されていますが、サポートされているメディア形式が答えるのは、そのデバイスが形式を処理できるかどうかだけであり、ネットワークがストリームを十分な速度で配信できるかどうかではありません。互換性と転送容量は、互いに独立した判定条件です。

これは、このフレームワークで最も重要な停止ルールです。サーバーが処理能力の範囲内でデータを送信しているにもかかわらず、Direct Play セッションでバッファリングが発生し、ネットワーク測定でパケットロスやスループット不足が確認された場合は、コーデックを理由にクライアントを交換したり、より高性能なトランスコーダーを購入したりしないでください。まず配信経路を改善します。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

大規模に変換が避けられない場合は、トランスコード性能が有利になる

すべての端末やネットワーク環境を統一できない家庭もあります。リモートユーザーには低いビットレートが必要な場合があり、古いテレビは新しいコーデックに対応していないことがあり、家族が使うデバイスは所有者の管理外にあることもあります。こうした変換が頻繁かつ正当な理由で発生する場合、中央のトランスコード能力を高めることが、拡張可能な対策になります。

FFmpegは、ストリームコピーと、デコード・フィルター・エンコード処理を区別します。そのトランスコードに関するドキュメントから、変換が必要になって初めてサーバーの性能が重要になる理由がわかります。互換性のあるストリームをコピーすればコーデック処理を避けられますが、変換ではデコードとエンコードの段階が発生し、フィルターが追加されることもあります。

測定したトランスコードがリアルタイム速度を維持できない場合、ビデオエンジンが飽和している場合、または避けられない同時変換の数が現在のシステムの処理能力を超える場合は、サーバーをアップグレードしてください。同じファイルをダイレクトプレイできる安価なクライアント1台のために、より高速なGPUで補うのは避けましょう。

字幕とHDRによって、互換性があるように見えるストリームでも処理経路が変わる

デバイスがビデオコーデックに対応していても、選択した字幕やHDR要件によって負荷の高い処理が発生することがあります。一部のクライアントでは、画像ベースの字幕をビデオに焼き込む必要があり、ディスプレイまたはクライアントの処理経路でソースを正しく表示できない場合は、HDRからSDRへのトーンマッピングによって別の処理段階が加わることがあります。

Appleが公開しているApple TVの再生仕様には、対応するビデオ形式、プロファイル、フレームレート、HDRモード、音声機能が記載されています。このデバイス形式の仕様から、「HEVCに対応」や「4Kに対応」だけでは完全な互換性テストにならない理由がわかります。プロファイル、コンテナ、HDR、音声、字幕の挙動によって、実際の処理経路が変わることがあります。

ハードウェアを交換する前に、問題が発生する組み合わせを正確にテストしてください。字幕を無効にする、テキスト字幕を選択する、SDR版を試す、または音声トラックを変更して、ビデオのトランスコードが停止するか確認します。1つの機能によってセッションの処理経路が変わる場合、その互換性の問題を解決するほうが、サーバー全体を増強するより安価なことがあります。

1台のエンドポイントを修正するコストと、すべてのストリームを修正するコストを比較する

クライアントのアップグレードは、個別の修正です。リビングルームの1台のデバイスが問題を引き起こしている場合に効率的で、そのエンドポイントで今後行われるすべてのセッションについて、サーバーの消費電力を削減できます。ただし、互換性のないクライアントが増えるたびに、それぞれに専用のアプリ、設定、またはハードウェア変更が必要になる可能性があります。

サーバーのアップグレードは一元的に行えます。より高性能なトランスコーダーなら、各エンドポイントを変更せずに複数の性能の低いクライアントへ対応できますが、その分サーバーがより多くの電力、冷却、ドライバー、ハードウェアアクセラレーションの複雑さを担うことになります。ZimaSpaceの関連記事にあるコンパクトなx86メディアサーバーとAndroid TVボックスの比較では、デバイスの役割についてより広い文脈で説明しています。このフレームワークでは、その選択をバッファリングの原因に絞り込みます。

避けられない変換ケースが増えるほど、判断はクライアント優先からサーバー優先へ切り替わります。互換性のないエンドポイントが1台だけなら、そのエンドポイントの修正が有効です。混在する機器環境でリモート変換が頻繁に発生するなら、ネットワークがボトルネックでないことを条件に、中央のトランスコード性能を強化するのが有効です。

このアップグレード順序の決定ツリーを使用する

このフレームワークは、一般的な推奨事項ではなく、実行可能な順序で終えるべきです。可能であれば、同じ問題のあるタイトルを少なくとも2台のクライアントで再生し、サーバーに表示される再生理由を確認してから、一度に1つの変数だけを変更してください。そうすれば、クライアントの制限をサーバーの制限と取り違えずに済みます。

各手順の後に結果を検証できるようにしてください。クライアント優先の変更は、セッションがダイレクトプレイまたはより軽いダイレクトストリームに移行すれば成功です。サーバー優先の変更は、想定される同時ストリーム数のもとで、必要なトランスコードが余裕を持って再生を維持できれば成功です。

どちらの変更でも問題のストリームが改善しない場合は、最初の確認段階に戻り、配信、ストレージ、またはアプリケーションが報告する理由を調べてください。意思決定ツリーは、関係のないアップグレードを止められる場合にのみ役立ちます。

よくある質問

より高速なトランスコーダーでダイレクトプレイは改善しますか？

いいえ。ダイレクトプレイでは動画変換が行われないため、CPUやGPUのトランスコード性能を追加しても、クライアントが元のストリームをより速くデコードできるようにはなりません。ダイレクトプレイでバッファリングが発生する場合は、ネットワーク配信、クライアントの再生動作、ストレージを調べてください。

字幕だけで動画のトランスコードが強制されることはありますか？

はい。一部の字幕形式やクライアントの組み合わせでは、字幕を動画に焼き込む必要があり、互換性のあるストリームが動画処理ジョブに変わってしまいます。動画コーデックを疑う前に、同じファイルを字幕なしでテストしてください。

トランスコードを避けるために、古いクライアントをすべて交換すべきですか？

必ずしもそうとは限りません。問題のあるエンドポイントを1台交換するのは効率的でも、混在するすべての機器を交換するのは効率的でない場合があります。互換性のあるクライアントはダイレクトプレイのまま使用し、変換を避けられないデバイスやリモート環境に対しては、サーバーのトランスコード性能を確保してください。

再生経路で最初に現れる原因を修正する

少数のエンドポイントが不要なトランスコードを引き起こしている場合は、まずクライアント互換性を選びます。最良の結果は、より高速なトランスコードではなく、不要な変換をなくしてサーバーから元のメディアを送信できるようにすることです。

多くのデバイスやリモートセッションで実際に変換が必要で、現在のサーバーがリアルタイム処理を維持できない場合は、まずトランスコード性能を選びます。ご家庭で使用する正確なコーデック、字幕、HDRモード、出力解像度について、ハードウェアアクセラレーションの対応状況と同時処理能力を確認してください。

ストリームがすでにダイレクトプレイで再生されている、またはネットワークが配信ビットレートに対応できない場合は、この2つのアップグレードを比較するのをやめてください。最初に対処すべきなのは、ベンチマーク値が大きいコンポーネントではなく、再生経路で最初に測定されたボトルネックです。