マルチユーザーストリーミングがJellyfinのトランスコーディングワークフローをどう変えるか

エヴァ・ウォン

IceWhale author

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

How Multi-User Streaming Changes Jellyfin’s Transcoding Workflow - Zima Store Online

マルチユーザーストリーミングでは、Jellyfinは単一の再生経路から共有キューへと変わり、ボトルネックは各クライアントの互換性とビットレートによって決まります。

家庭内では、ダイレクト再生のテレビストリーム、字幕付きのタブレットセッション、リモート接続のスマートフォンセッションが数分以内に同時に始まることがあります。これらのリクエストが消費するリソースは同じではありません。1つはストレージを読み取るだけで済み、別の1つは動画トランスコードで字幕を焼き込み、リモートクライアントはアップロード帯域の制約を加える可能性があります。ユーザー数だけを数えるよりも、この負荷の偏りを理解するほうが有用です。

1つのユーザーリクエストがたどる4つの異なる経路

Jellyfinはまず、メディアコンテナ、動画コーデック、音声コーデック、字幕、解像度、ビットレートを、リクエスト元のクライアントが処理できると報告している内容と比較します。その比較によって、ダイレクト再生、リマックス、音声変換、完全な動画トランスコードのいずれかが選択されるため、同じタイトルを開いた2人のユーザーでも、サーバーに発生する処理は大きく異なる場合があります。

元のファイルを受け入れられるクライアントでは、サーバーは主にファイルリーダーとして機能します。一方、互換性のないブラウザでは、デコードとエンコードの工程が必要になることがあります。ダイレクト再生の動作についての実用的な解説が示すように、変換を避けることで、経路上の処理負荷を大幅に減らせます。

その結果として現れるのが非対称な負荷です。互換性の境界を越えるリクエストが発生するまでは、ストリーム数が増えてもCPU使用率が比例して増えないことがあります。したがって、正しく数えるべき単位は「ユーザー」ではなく、ダイレクト再生、リマックス、音声トランスコード、動画トランスコードのセッション構成です。

同時トランスコードは特定のパイプライン工程で競合する

完全なトランスコードは、読み取り、デコード、フィルタリング、エンコード、一時セグメントの書き込み、配信という一連の工程で構成されます。複数のセッションが、ハードウェア動画エンジン、CPUによる字幕レンダリング、トランスコードキャッシュ、外向きネットワーク回線など、同じ希少な工程を必要とすると、同時実行の影響が現れます。

ハードウェアアクセラレーションによってデコードとエンコードを汎用CPUコアから切り離せますが、フィルタリング、字幕、ストレージ、ネットワークのコストまで消えるわけではありません。ハードウェアアクセラレーション対応トランスコードに関する実際の説明でも、GPUへのオフロードと、完全に負荷のないパイプラインは一貫して区別されています。

最も遅い共有工程が、再生で消費される速度よりも速くメディアを生成できなくなると、キューが増え、クライアントのバッファが使い果たされます。別の場所にある高速なコンポーネントでは補えません。余っているCPUでは飽和したアップロード回線を解決できず、余っている帯域幅ではソフトウェアによる字幕の焼き込みを解決できません。

オープンソースの制御性が容量計画を変える

Jellyfinは再生方式の決定を可視化し、FFmpegベースの変換を、ハードウェアアクセラレーションをサブスクリプション階層の背後に隠すことなく利用します。そのため、ワークフローを検証・設定できますが、ドライバー、デバイスアクセス、コーデック、クライアントの動作を適切に組み合わせる責任は運用者にあります。

この制御性の価値は、ホームサーバーで複数のアプリケーションを動かし、どのワークロードをGPUで共有するか、あるいはバックグラウンドジョブをいつ実行するかを所有者が決められる場面で現れます。クライアント制限パイプラインは単一セッションの基盤を提供します。マルチユーザーの計画では、そこにパイプライン同士の競合が加わります。完全な配信経路を考慮すれば、同じ運用上の境界はダイレクト再生の動作にも当てはまります。

つまり、オープンソースが変えるのは誰がシステムを調整できるかであり、変換にかかる物理的なコストではありません。制御項目が増えてもスループットが自動的に増えるわけではなく、アクセラレーション経路の設定を誤ると、インターフェース上は利用可能に見えたまま、CPU処理へ静かにフォールバックすることがあります。

-15% OFF

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

Single board computer zimaboard2

ユーザー数だけではパフォーマンスを予測できなくなる地点

多くのクライアントがダイレクト再生を利用している場合、ユーザー数は予測指標として弱くなります。互換性のある1080pセッションが多数ある場合でも、難易度の高いHDR字幕セッションが2つあるだけで、それ以上の負荷になることがあります。また、ストレージやアップロード回線がすでに飽和している場合も、この見方は当てはまりません。その時点では、トランスコード能力が制御要因ではなくなっているからです。

リモート接続の同時実行数は、表面的なダウンロード速度ではなく、実際に利用可能な上り帯域と照らし合わせて確認する必要があります。アップロード帯域をストリームのビットレートで割る計算に基づく帯域計画の例は、制限要因となる関係を明確にします。ただし、ソースのビットレートは変動するため、余裕を確保する必要があります。別の実地レポートでも、目に見える症状だけでボトルネックを判断せず、セッション単位のトランスコード指標を使うことが支持されています。

ハードウェアを変更する前に、4項目からなるセッション台帳を作成してください。同時に接続している各クライアントについて、再生モード、ソースと配信後のビットレート、字幕方式、稼働中のCPU/GPUエンジンを記録します。繰り返し行ったテストで同じ工程の飽和が確認された場合にのみアップグレードし、それ以外の場合はまず、互換性のないクライアント、メディアのバージョン、または帯域幅の目標を変更してください。