XenApp and XenDesktop

マルチメディア

May 20, 2026

寄稿者:

C C

HDX™テクノロジースタックは、2つの補完的なアプローチを通じてマルチメディアアプリケーションの配信をサポートします。

サーバー側レンダリングによるマルチメディア配信
クライアント側レンダリングによるマルチメディアリダイレクト

この戦略により、優れたユーザーエクスペリエンスで幅広いマルチメディア形式を配信できると同時に、サーバーのスケーラビリティを最大化してユーザーあたりのコストを削減できます。

サーバーレンダリングによるマルチメディア配信では、オーディオおよびビデオコンテンツは、アプリケーションによってXenAppまたはXenDesktopサーバー上でデコードおよびレンダリングされます。その後、コンテンツは圧縮され、ICAプロトコルを介してユーザーデバイス上のCitrix Receiverに配信されます。この方法により、さまざまなアプリケーションやメディア形式との互換性が最高レベルで提供されます。ビデオ処理は計算負荷が高いため、サーバーレンダリングによるマルチメディア配信は、オンボードのハードウェアアクセラレーションから大きな恩恵を受けます。たとえば、DirectX Video Acceleration (DXVA) のサポートにより、H.264デコードを個別のハードウェアで実行することでCPUの負荷が軽減されます。Intel Quick SyncおよびNVIDIA NVENCテクノロジーは、ハードウェアアクセラレーションによるH.264エンコーディングを提供しました。

ほとんどのサーバーはビデオ圧縮用のハードウェアアクセラレーションを提供しないため、すべてのビデオ処理がサーバーCPUで行われる場合、サーバーのスケーラビリティに悪影響が及びます。高いサーバーのスケーラビリティを維持するために、多くのマルチメディア形式をローカルレンダリングのためにユーザーデバイスにリダイレクトできます。Windows Mediaリダイレクトは、通常Windows Media Playerに関連付けられているさまざまなメディア形式について、サーバーの負荷を軽減します。

Flashリダイレクトは、Adobe Flashビデオコンテンツをユーザーデバイス上でローカルに実行されているFlashプレーヤーにリダイレクトします。 HTML5ビデオは普及しており、Citrix®はこの種のコンテンツ向けにリダイレクトテクノロジーを導入しました。また、一般的なコンタクトリダイレクトテクノロジーであるHost-to-clientリダイレクトとLocal App Accessをマルチメディアコンテンツに適用することもできます。

これらのテクノロジーを組み合わせると、リダイレクトを構成しない場合、HDXはServer-Side Renderingを実行します。リダイレクトを構成する場合、HDXはServer Fetch and Client RenderまたはClient Fetch and Client Renderのいずれかを使用します。これらの方法が失敗した場合、HDXは必要に応じてServer-Side Renderingにフォールバックし、Fallback Prevention Policyの対象となります。

シナリオ例

ローカライズされた画像

シナリオ 1. (サーバーフェッチおよびサーバーレンダリング):

サーバーは、ソースからメディアファイルを取得し、デコードしてから、オーディオデバイスまたはディスプレイデバイスにコンテンツを提示します。
サーバーは、提示された画像またはサウンドをそれぞれディスプレイデバイスまたはオーディオデバイスから抽出します。
サーバーは、必要に応じてそれを圧縮し、クライアントに送信します。

このアプローチは、高いCPUコスト、高い帯域幅コスト（抽出された画像/サウンドが効率的に圧縮されていない場合）、および低いサーバー拡張性をもたらします。

Thinwireおよびオーディオ仮想チャネルがこのアプローチを処理します。このアプローチの利点は、クライアントのハードウェアおよびソフトウェア要件を削減することです。このアプローチを使用すると、デコードはサーバー上で行われ、より幅広い種類のデバイスとフォーマットで動作します。

シナリオ2。（サーバーフェッチとクライアントレンダリング）：

このアプローチは、メディアコンテンツがデコードされてオーディオまたはディスプレイデバイスに提示される前に、それを傍受できることに依存しています。圧縮されたオーディオ/ビデオコンテンツは、代わりにクライアントに送信され、そこでローカルにデコードおよび提示されます。このアプローチの利点は、デコードと提示がクライアントデバイスにオフロードされ、サーバーのCPUサイクルを節約できることです。

ただし、クライアントにはいくつかの追加のハードウェアおよびソフトウェア要件も発生します。クライアントは、受信する可能性のある各フォーマットをデコードできる必要があります。

シナリオ3。（クライアントフェッチとクライアントレンダリング）：

このアプローチは、メディアコンテンツがソースからフェッチされる前に、そのURLを傍受できることに依存しています。URLはクライアントに送信され、そこでメディアコンテンツがフェッチ、デコード、およびローカルに提示されます。このアプローチは概念的にシンプルです。その利点は、サーバーのCPUサイクルと帯域幅の両方を節約できることです。なぜなら、サーバーからは制御コマンドのみが送信されるからです。ただし、メディアコンテンツが常にクライアントからアクセスできるとは限りません。

フレームワークとプラットフォーム

デスクトップオペレーティングシステム（Windows、Mac OS X、Linux）は、マルチメディアアプリケーションのより迅速かつ容易な開発を可能にするマルチメディアフレームワークを提供します。この表は、より一般的なマルチメディアフレームワークの一部をリストしています。各フレームワークは、メディア処理をいくつかの段階に分け、パイプラインベースのアーキテクチャを使用します。

フレームワーク	プラットフォーム
ダイレクトショー	ウィンドウズ (98以降)
メディアファンデーション	ウィンドウズ (Vista以降)
Gstreamer	Linux
クイックタイム	Mac OS エックス

メディアリダイレクト技術によるダブルホップサポート

メディアリダイレクト	サポート
HDX Flashリダイレクト	いいえ
Windows Media のリダイレクト機能	はい
HTML5ビデオのリダイレクト	はい
オーディオリダイレクト	いいえ

マルチメディア

シナリオ例

フレームワークとプラットフォーム

メディアリダイレクト技術によるダブルホップサポート

関連する情報

この記事の概要