-
Pianificare e creare una distribuzione
-
Creare e gestire le connessioni
-
Creare cataloghi di macchine con immagini preparate
-
Creare un'immagine preparata per le istanze gestite di Amazon WorkSpaces Core
-
Creare un catalogo di istanze gestite di Amazon WorkSpaces Core
-
Creare un catalogo di macchine con immagini preparate in Azure
-
Creare un catalogo di macchine con immagini preparate in Red Hat OpenShift
-
Creare un catalogo di macchine con immagini preparate in VMware
-
Creare un catalogo di macchine con immagini preparate in XenServer
-
-
Pool di identità di diversi tipi di join di identità delle macchine
-
-
Multimedia
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
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
Scenario 1. (Recupero dal server e rendering sul server):
- 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.
- Il server estrae l’immagine o il suono presentato dal dispositivo di visualizzazione o dal dispositivo audio rispettivamente.
- 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 | Sì | |
Reindirizzamento video HTML5 | Sì | |
Reindirizzamento di Windows Media | Sì |
Condividi
Condividi
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.