製品ドキュメント
Citrix Virtual Apps and Desktops
Service Current Release 2402 LTSR 2311 2308 2305 2303 2212 2209 2206 2203 LTSR 1912 LTSR
PDFを表示

マルチメディア

January 4, 2023
寄稿者: 
C

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サイトについては、Webブラウザーコンテンツのリダイレクトをお勧めします。
  • 一般的な連絡先リダイレクト機能である、ホストからクライアントへのリダイレクトとローカルアプリアクセスを、マルチメディアコンテンツに応用できます。

これらの機能を含めて、リダイレクトを構成しない場合は、HDXはサーバー側でのレンダリングを実行します。 リダイレクトを構成する場合、HDXはサーバー側でフェッチし、クライアント側でレンダリング、またはクライアント側でフェッチし、クライアント側でレンダリングのいずれかを実行します。これらの方法が失敗した場合、HDXは必要に応じてサーバー側でのレンダリングにフォールバックし、フォールバック防止ポリシーの対象になります。

サンプルシナリオ

サンプルシナリオ

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

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

このアプローチでは、（抽出されたイメージやサウンドが効率的に圧縮されていない場合は）高CPUコストと高帯域幅コストを負担することになり、サーバースケーラビリティは低くなります。

Thinwireとオーディオの仮想チャネルがこのアプローチを処理します。このアプローチの利点により、クライアントのハードウェアとソフトウェアの要件が削減されます。このアプローチでは、デコーディングはサーバーで実行され、より多くの種類のデバイスとフォーマットに対応します。

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

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

ただし、このアプローチでは、クライアントにハードウェアとソフトウェアの要件が一部追加されます。クライアントは、受信する可能性のあるそれぞれのフォーマットをデコードできる必要があります。

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

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

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

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

フレームワーク プラットフォーム
DirectShow Windows（98以降）
Media Foundation Windows（Vista以降）
Gstreamer Linux
Quicktime Mac OS X

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

この記事の概要

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