Citrix DaaS™

Multimedia

Lo stack tecnologico HDX™ supporta la distribuzione di applicazioni multimediali tramite due approcci complementari:

  • Distribuzione multimediale con rendering lato server
  • Reindirizzamento multimediale con rendering lato client

Questa strategia garantisce la possibilità di distribuire una gamma completa di formati multimediali, con un’ottima esperienza utente, massimizzando al contempo la scalabilità del server per ridurre il costo per utente.

Con la distribuzione multimediale con rendering lato server, il contenuto audio e video viene decodificato e renderizzato sul server Citrix DaaS (precedentemente servizio Citrix Virtual Apps and Desktops) dall’applicazione. Il contenuto viene quindi compresso e distribuito utilizzando il protocollo ICA all’app Citrix Workspace sul dispositivo utente. Questo metodo offre il più alto tasso di compatibilità con varie applicazioni e formati multimediali. Poiché l’elaborazione video è ad alta intensità di calcolo, la distribuzione multimediale con rendering lato server beneficia notevolmente dell’accelerazione hardware integrata. Ad esempio, il supporto per DirectX Video Acceleration (DXVA) alleggerisce la CPU eseguendo la decodifica H.264 in hardware separato. Le tecnologie Intel Quick Sync, AMD RapidFire e NVIDIA NVENC forniscono la codifica H.264 accelerata dall’hardware.

Poiché la maggior parte dei server non offre alcuna accelerazione hardware per la compressione video, la scalabilità del server viene influenzata negativamente se tutta l’elaborazione video viene eseguita sulla CPU del server. È possibile mantenere un’elevata scalabilità del server reindirizzando molti formati multimediali al dispositivo utente per il rendering locale.

  • Il reindirizzamento di Windows Media alleggerisce il server per un’ampia varietà di formati multimediali tipicamente associati a Windows Media Player.
  • Il video HTML5 è diventato popolare e Citrix® ha introdotto una tecnologia di reindirizzamento per questo tipo di contenuto. Si consiglia il reindirizzamento del contenuto del browser per i siti Web che utilizzano HTML5, HLS, DASH o WebRTC.
  • È possibile applicare le tecnologie generali di reindirizzamento dei contatti, il reindirizzamento da host a client e l’accesso app locale, al contenuto multimediale.

Mettendo insieme queste tecnologie, se non si configura il reindirizzamento, HDX esegue il rendering lato server. Se si configura il reindirizzamento, HDX utilizza il recupero dal server e rendering sul client o il recupero dal client e rendering sul client. Se questi metodi falliscono, HDX esegue il fallback al rendering lato server, se necessario, ed è soggetto al Criterio di prevenzione del fallback.

Scenari di esempio

Example scenario

Scenario 1. (Recupero dal server e rendering sul server):

  1. Il server recupera il file multimediale dalla sua origine, lo decodifica e quindi presenta il contenuto a un dispositivo audio o a un dispositivo di visualizzazione.
  2. Il server estrae l’immagine o il suono presentato dal dispositivo di visualizzazione o dal dispositivo audio rispettivamente.
  3. Il server lo comprime facoltativamente e quindi lo trasmette al client.

Questo approccio comporta un costo elevato per la CPU, un costo elevato per la larghezza di banda (se l’immagine/suono estratto non è compresso in modo efficiente) e ha una bassa scalabilità del server.

I canali virtuali Thinwire e Audio gestiscono questo approccio. Il vantaggio di questo approccio è che riduce i requisiti hardware e software per i client. Utilizzando questo approccio, la decodifica avviene sul server e funziona per una più ampia varietà di dispositivi e formati.

Scenario 2. (Recupero dal server e rendering sul client):

Questo approccio si basa sulla capacità di intercettare il contenuto multimediale prima che venga decodificato e presentato al dispositivo audio o di visualizzazione. Il contenuto audio/video compresso viene invece inviato al client dove viene quindi decodificato e presentato localmente. Il vantaggio di questo approccio è che viene scaricato sui dispositivi client, risparmiando cicli della CPU sul server.

Tuttavia, introduce anche alcuni requisiti hardware e software aggiuntivi per il client. Il client deve essere in grado di decodificare ogni formato che potrebbe ricevere.

Scenario 3. (Recupero dal client e rendering sul client):

Questo approccio si basa sulla capacità di intercettare l’URL del contenuto multimediale prima che venga recuperato dalla sorgente. L’URL viene inviato al client dove il contenuto multimediale viene recuperato, decodificato e presentato localmente. Questo approccio è concettualmente semplice. Il suo vantaggio è che consente di risparmiare cicli della CPU sul server e larghezza di banda perché il server invia solo comandi di controllo. Tuttavia, il contenuto multimediale non è sempre accessibile ai client.

Framework e piattaforma:

I sistemi operativi a sessione singola (Windows, Mac OS X e Linux) forniscono framework multimediali che consentono uno sviluppo più rapido delle applicazioni multimediali. Questa tabella elenca alcuni dei framework multimediali più popolari. Ogni framework divide l’elaborazione multimediale in diverse fasi e utilizza un’architettura basata su pipeline.

Framework Piattaforma
DirectShow Windows (98 e successivi)
Media Foundation Windows (Vista e successivi)
Gstreamer Linux
Quicktime Mac OS X

Supporto double hop con tecnologie di reindirizzamento multimediale

  Reindirizzamento audio No
  Reindirizzamento del contenuto del browser No
  Reindirizzamento webcam HDX
  Reindirizzamento video HTML5
  Reindirizzamento di Windows Media
Multimedia