マルチメディア
HDX™ テクノロジースタックは、2つの補完的なアプローチを通じてマルチメディアアプリケーションの配信をサポートします。
-
サーバー側レンダリングによるマルチメディア配信
-
クライアント側レンダリングによるマルチメディアリダイレクト
この戦略により、優れたユーザーエクスペリエンスで幅広いマルチメディア形式を配信し、サーバーのスケーラビリティを最大化してユーザーあたりのコストを削減できます。
サーバーレンダリングによるマルチメディア配信では、オーディオおよびビデオコンテンツは、アプリケーションによってCitrix Virtual Apps and Desktopsサーバー上でデコードおよびレンダリングされます。その後、コンテンツは圧縮され、ICAプロトコルを使用してユーザーデバイス上のCitrix Workspaceアプリに配信されます。この方法は、さまざまなアプリケーションやメディア形式との互換性が最も高くなります。ビデオ処理は計算負荷が高いため、サーバーレンダリングによるマルチメディア配信は、オンボードのハードウェアアクセラレーションから大きな恩恵を受けます。たとえば、DirectX Video Acceleration (DXVA) のサポートにより、H.264デコードを個別のハードウェアで実行することでCPUの負荷が軽減されます。Intel Quick Sync、AMD RapidFire、NVIDIA NVENCテクノロジーは、ハードウェアアクセラレーションによるH.264エンコードを提供します。
ほとんどのサーバーはビデオ圧縮用のハードウェアアクセラレーションを提供しないため、すべてのビデオ処理がサーバーCPUで行われると、サーバーのスケーラビリティに悪影響が及びます。多くのマルチメディア形式をユーザーデバイスにリダイレクトしてローカルでレンダリングすることで、高いサーバーのスケーラビリティを維持できます。
-
Windows Mediaリダイレクトは、通常Windows Media Playerに関連付けられているさまざまなメディア形式について、サーバーの負荷を軽減します。
-
HTML5ビデオは普及しており、Citrix®はこの種のコンテンツ向けのリダイレクトテクノロジーを導入しました。HTML5、HLS、DASH、またはWebRTCを使用するWebサイトには、ブラウザーコンテンツリダイレクトをお勧めします。
-
一般的なコンテンツリダイレクトテクノロジーであるHost-to-client redirectionおよびLocal App Accessをマルチメディアコンテンツに適用できます。
これらのテクノロジーを組み合わせると、リダイレクトを設定しない場合、HDXはサーバー側レンダリングを実行します。 リダイレクトを設定すると、HDXはサーバーフェッチとクライアントレンダリング、またはクライアントフェッチとクライアントレンダリングのいずれかを使用します。これらの方法が失敗した場合、HDXは必要に応じてサーバー側レンダリングにフォールバックし、フォールバック防止ポリシーの対象となります。
シナリオ例
シナリオ1。（サーバーフェッチとサーバーレンダリング）：
-
サーバーはソースからメディアファイルを取得し、デコードしてから、オーディオデバイスまたはディスプレイデバイスにコンテンツを提示します。
-
サーバーは、表示デバイスまたはオーディオデバイスから、それぞれ提示された画像またはサウンドを抽出します。
-
サーバーは必要に応じてそれを圧縮し、クライアントに送信します。
このアプローチでは、高いCPUコスト、高い帯域幅コスト（抽出された画像/サウンドが効率的に圧縮されていない場合）、および低いサーバーのスケーラビリティが発生します。
Thinwireおよびオーディオ仮想チャネルがこのアプローチを処理します。このアプローチの利点は、クライアントのハードウェアおよびソフトウェア要件を削減することです。このアプローチを使用すると、デコードはサーバー上で行われ、より幅広い種類のデバイスとフォーマットで動作します。
シナリオ2。（サーバーフェッチとクライアントレンダリング）：
このアプローチは、メディアコンテンツがデコードされ、オーディオまたは表示デバイスに提示される前に傍受できることに依存します。圧縮されたオーディオ/ビデオコンテンツは、代わりにクライアントに送信され、そこでローカルにデコードおよび提示されます。このアプローチの利点は、それらがクライアントデバイスにオフロードされ、サーバーのCPUサイクルを節約できることです。
しかし、これはクライアントに追加のハードウェアおよびソフトウェア要件ももたらします。クライアントは、受信する可能性のある各フォーマットをデコードできる必要があります。
シナリオ3。（クライアントフェッチとクライアントレンダリング）：
このアプローチは、メディアコンテンツのURLがソースからフェッチされる前に傍受できることに依存します。URLはクライアントに送信され、そこでメディアコンテンツがフェッチ、デコード、およびローカルに提示されます。このアプローチは概念的にシンプルです。その利点は、サーバーが制御コマンドのみを送信するため、サーバーのCPUサイクルと帯域幅の両方を節約できることです。ただし、メディアコンテンツが常にクライアントからアクセスできるとは限りません。
フレームワークとプラットフォーム：
シングルセッションオペレーティングシステム（Windows、Mac OS X、Linux）は、マルチメディアアプリケーションのより迅速な開発を可能にするマルチメディアフレームワークを提供します。この表は、より一般的なマルチメディアフレームワークの一部を示しています。各フレームワークは、メディア処理をいくつかの段階に分割し、パイプラインベースのアーキテクチャを使用します。
| フレームワーク | プラットフォーム |
|---|---|
| DirectShow | Windows (98以降) |
| メディア ファンデーション | ウィンドウズ (Vista以降) |
| Gストリーマー | リナックス |
| クイックタイム | マック オーエス テン |
メディアリダイレクトテクノロジーでのダブルホップサポート
| オーディオリダイレクト | いいえ |
| ブラウザコンテンツリダイレクト | いいえ |
| HDX Webカメラリダイレクト | はい |
| HTML5ビデオのリダイレクト | はい |
| Windows Mediaリダイレクト | はい |