製品ドキュメント
Citrix DaaS™
PDFを表示

マルチメディア

April 2, 2026
寄稿者: 
C C

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

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

  • クライアント側レンダリングによるマルチメディアリダイレクト

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

  • サーバーレンダリングによるマルチメディア配信では、オーディオおよびビデオコンテンツは、アプリケーションによってCitrix DaaS（旧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サイトには、ブラウザーコンテンツリダイレクトをお勧めします。
  • 一般的なコンタクトリダイレクトテクノロジーであるホストからクライアントへのリダイレクトとローカルアプリアクセスをマルチメディアコンテンツに適用できます。

これらのテクノロジーを組み合わせると、リダイレクトを設定しない場合、HDXはサーバー側レンダリングを実行します。リダイレクトを設定すると、HDXはサーバーフェッチとクライアントレンダリング、またはクライアントフェッチとクライアントレンダリングのいずれかを使用します。これらの方法が失敗した場合、HDXは必要に応じてサーバー側レンダリングにフォールバックし、フォールバック防止ポリシーの対象となります。

シナリオ例

シナリオ例

シナリオ 1.（サーバーフェッチとサーバーレンダリング）:

  1. サーバーはソースからメディアファイルをフェッチし、デコードしてから、オーディオデバイスまたはディスプレイデバイスにコンテンツを提示します。
  2. サーバーは、提示された画像またはサウンドをそれぞれディスプレイデバイスまたはオーディオデバイスから抽出します。
  3. サーバーはオプションでそれを圧縮し、クライアントに送信します。

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

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

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

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

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

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

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

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

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

フレームワーク プラットフォーム
DirectShow Windows (98 and later)
Media Foundation Windows (Vista and later)
Gstreamer Linux
Quicktime Mac OS X

メディアリダイレクト技術によるダブルホップサポート
  オーディオリダイレクト いいえ
  ブラウザーコンテンツリダイレクト いいえ
  HDX Webカメラリダイレクト はい
  HTML5ビデオのリダイレクト はい
  Windows Mediaリダイレクト はい
マルチメディア
April 2, 2026
寄稿者: 
C C
April 2, 2026
寄稿者: 
C C

この記事の概要

サイトに関するフィードバック | Your privacy choices footer linkプライバシーに関する選択肢 | プライバシーと法令 | Cookieの設定 | 同意設定 | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.