多媒体
HDX技术栈通过两种互补的方式支持多媒体应用程序的交付:
- 服务器端呈现多媒体交付
- 客户端呈现多媒体重定向
此策略确保您可以交付各种多媒体格式，并提供出色的用户体验，同时最大限度地提高服务器可伸缩性以降低每个用户的成本。
通过服务器渲染的多媒体传输，音频和视频内容由应用程序在Citrix DaaS(以前称为Citrix虚拟应用程序和桌面服务)服务器上解码和渲染。然后将内容压缩并使用ICA协议交付到用户设备上的Citrix Workspace应用程序。这种方法提供了与各种应用程序和媒体格式的最高兼容性。由于视频处理是计算密集型的，服务器呈现的多媒体传输从板载硬件加速中受益匪浅。例如，对DirectX视频加速(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的网站使用浏览器内容重定向。
- 多媒体内容可以应用一般的联系人重定向技术:主机到客户端重定向技术和本地应用访问技术。
把这些技术放在一起，如果你不配置重定向，HDX做服务器端渲染。如果您配置重定向，HDX使用服务器获取和客户端渲染或客户端获取和客户端渲染。如果这些方法失败，HDX将根据需要退回到服务器端渲染，并遵循回退预防策略。
示例场景
场景1。(服务器获取和服务器渲染):
- 服务器从其源获取媒体文件，进行解码，然后将内容呈现给音频设备或显示设备。
- 服务器分别从显示设备或音频设备提取所呈现的图像或声音。
- 服务器可选择对其进行压缩，然后将其传输到客户端。
这种方法会导致高CPU成本和高带宽成本(如果提取的图像/声音没有被有效压缩)，并且服务器可伸缩性较低。
Thinwire和Audio虚拟通道处理这种方法。这种方法的优点是它减少了客户机的硬件和软件需求。使用这种方法，解码发生在服务器上，它适用于各种各样的设备和格式。
场景2。(服务器获取和客户端渲染):
这种方法依赖于能够在媒体内容被解码并呈现给音频或显示设备之前拦截媒体内容。压缩的音频/视频内容被发送到客户端，然后在客户端进行解码并在本地呈现。这种方法的优点是，它们被卸载到客户机设备上，从而节省了服务器上的CPU周期。
但是，它还为客户机引入了一些额外的硬件和软件需求。客户端必须能够解码它可能接收到的每种格式。
场景3。(客户端获取和客户端渲染):
这种方法依赖于能够在从源获取媒体内容URL之前拦截它。URL被发送到客户端，在客户端获取、解码媒体内容并在本地呈现。这种方法在概念上很简单。它的优点是节省了服务器上的CPU周期和带宽，因为服务器只发送控制命令。但是，客户端并不总是能够访问媒体内容。
框架和平台:
单会话操作系统(Windows、Mac OS X和Linux)提供了多媒体框架，可以更快地开发多媒体应用程序。下表列出了一些比较流行的多媒体框架。每个框架将媒体处理分为几个阶段，并使用基于管道的体系结构。
| 框架 | 平台 |
|---|---|
| DirectShow的 | Windows(98及更高版本) |
| 媒体基金会 | Windows (Vista及更高版本) |
| Gstreamer | Linux |
| Quicktime | Mac OS X |
双跳支持媒体重定向技术
| 音频重定向 | 没有 |
| 浏览器内容重定向 | 没有 |
| HDX网络摄像头重定向 | 是的 |
| HTML5视频重定向 | 是的 |
| Windows Media重定向 | 是的 |