Moonlight vs Parsec vs RDP : bureau distant pour le rendu GPU 2026

Introduction

Le bureau distant est devenu silencieusement un élément porteur des workflows de cloud rendering. Lorsqu'un artiste à Berlin doit inspecter un rendu de prévisualisation interactive sur un nœud GPU situé dans un data center en Virginie, c'est la couche de bureau distant qui détermine si l'expérience ressemble à un travail local ou à un combat contre un flux vidéo saccadé. Pour l'édition de texte ou le travail léger d'image, presque tout outil de bureau distant fait l'affaire. Pour l'interaction du viewport 3D, l'IPR (Interactive Preview Rendering) dans Redshift ou Karma, les playblasts Houdini, ou le compositing critique en couleur dans Nuke, le choix du protocole devient la différence entre une workstation utilisable et inutilisable.

Le marché s'est consolidé autour de quatre options pratiques pour le bureau distant accéléré par GPU : Moonlight associé à Sunshine (open source, basé sur NVIDIA NVENC), Parsec (commercial-géré, pile de codecs similaire), Microsoft Remote Desktop avec RDP 10+ AVC444 (intégré à Windows), et les variantes VNC (TightVNC, TigerVNC, NoMachine, RustDesk). Chacune a une niche défendable, et la bonne réponse dépend de votre priorité : latence, qualité, sécurité, traversée NAT, coût de licence ou simplicité d'onboarding.

Ce guide parcourt les compromis de chaque protocole, la passerelle de qualité de configuration que nous utilisons avant de déclarer un bureau distant apte au travail 3D de production, et la pile de protocoles que nous déployons par défaut sur les clusters de rendu GPU dédiés. Pour un contexte plus large, notre page location de cluster GPU dédié couvre les patterns customer-owned-credentials et déploiement cross-country, et notre guide de déploiement complet parcourt l'architecture réseau de bout en bout.

Moonlight + Sunshine en détail

Moonlight et Sunshine sont l'appariement open source qui produit l'expérience de bureau distant GPU la plus réactive prête à l'emploi que nous ayons mesurée pour le travail 3D interactif. Sunshine est le serveur côté hôte (installé sur la machine à laquelle vous voulez accéder à distance), Moonlight est le client. Le protocole sous-jacent est GameStream de NVIDIA, conçu à l'origine pour streamer des jeux GPU d'une workstation vers une Shield TV en 4K 60 Hz avec une latence d'encodage d'une seule milliseconde. NVIDIA a abandonné le serveur GameStream officiel en 2023 ; Sunshine a réimplémenté le côté hôte en open source et l'a étendu aux encodeurs hardware AMD et Intel.

La raison pour laquelle Moonlight + Sunshine gagne pour le travail de rendu GPU se résume à l'encodage hardware. Sur une RTX 5090, NVENC est un bloc de silicium dédié qui gère l'encodage H.264, H.265 et AV1 sans toucher aux cœurs CUDA. Encoder un flux 4K 60fps coûte un pourcentage à un chiffre du calcul GPU et ajoute environ 5 à 15 millisecondes de latence du rendu au réseau. L'encodage software (utilisé par la plupart des variantes VNC) peut ajouter 30 à 100 millisecondes et consommer 20 à 40 pour cent d'un cœur CPU par flux. Pour un artiste qui scrubbe une timeline Houdini ou fait tourner une vue IPR Redshift, la différence est viscérale.

Diagramme du pipeline montrant comment une workstation de rendu capture, encode via NVENC, et diffuse un viewport GPU à un client distant.

Les réglages de qualité dans Moonlight sont inhabituellement configurables pour un outil gratuit. Le client expose une résolution cible (jusqu'à 4K, avec support multi-moniteur sur Sunshine 0.20 et plus récent), une fréquence d'images cible (généralement 60 fps ; 120 fps sur des liaisons capables), un plafond de bitrate (5 à 150 Mbps selon la liaison) et le choix du codec (H.264 baseline, H.265 Main 10 pour le travail HDR-aware, AV1 sur les hôtes RTX série 40 et plus récents). Pour la plupart des travaux d'archviz et de motion graphics, un défaut de 4K à 60 fps avec H.265 à 80 Mbps est confortable sur un uplink 100 Mbps, visuellement indistinguable du local pour le travail viewport interactif, et bien dans le budget d'encodage NVENC d'une RTX 5090.

Le support multi-moniteur compte plus que les utilisateurs débutants ne s'y attendent. Sunshine capture plusieurs moniteurs nativement, et le client Moonlight peut rendre tous les moniteurs dans une vue fusionnée ou les répartir sur des écrans côté client. Le protocole transporte la position du curseur et les événements de clic par moniteur, donc un éditeur de nœuds Houdini sur le moniteur deux et une prévisualisation de rendu Karma sur le moniteur un restent indépendamment réactifs.

Ce que Moonlight ne gère pas d'emblée, c'est la traversée NAT. Sunshine écoute sur un ensemble fixe de ports TCP et UDP, et un client Moonlight sur l'internet ouvert a besoin soit d'un port redirigé sur le routeur de l'hôte, soit d'un tunnel VPN qui place client et hôte sur le même réseau logique. Le pattern standard dans nos déploiements est un tunnel WireGuard — client et hôte se connectent tous deux à un petit endpoint WireGuard, et le trafic entre eux circule sur l'overlay UDP chiffré. Moonlight voit simplement une connexion LAN à faible latence. Pour notre approfondissement sur WireGuard + architecture réseau, cette intégration est couverte en détail.

Où Moonlight + Sunshine est limité : pas de canal de support commercial, l'onboarding pour les artistes non techniques requiert l'exécution d'un installateur et un pairing avec PIN unique, et l'expérience client Linux varie entre distributions. Pour les studios déployant l'accès à une flotte de nœuds GPU, la configuration par nœud est gérable ; pour un accès temporaire ad-hoc, la friction est réelle.

Caractéristiques de Parsec

Parsec est le pendant commercial-géré de Moonlight + Sunshine. Le cœur technique est similaire — H.264 ou H.265 encodé en hardware sur UDP avec faible latence d'encodage — mais la couche produit autour résout les problèmes d'onboarding et de traversée NAT que Moonlight open source laisse à l'utilisateur. Le compromis est le coût de licence et un broker de connexion géré dans le chemin de données.

Le tier gratuit de Parsec couvre l'usage individuel et les petites équipes, avec un tier Teams (payé par siège, facturation mensuelle) qui ajoute l'administration centralisée, single sign-on, enregistrement et l'attribution d'hôtes à des utilisateurs spécifiques sans pairing manuel. Pour les studios avec accès freelance rotatif, la couche admin centralisée est la valeur principale — un producteur peut accorder ou révoquer l'accès d'un artiste depuis une console web, sans toucher à la configuration WireGuard de l'hôte ni au pairing Sunshine.

Le broker de connexion est ce qui distingue mécaniquement Parsec de Moonlight. Client et hôte s'enregistrent tous deux auprès du service cloud de Parsec, et le broker coordonne le handshake initial (NAT punching, négociation de codec, pairing) avant que le flux vidéo réel ne circule en peer-to-peer sur UDP. Dans le cas commun, le flux lui-même ne passe pas par l'infrastructure de Parsec — il va directement entre client et hôte une fois le handshake fait. Dans la plupart des cas, aucune redirection de port n'est requise sur le réseau de l'hôte, ce qui est le plus gros avantage pratique sur Sunshine auto-hébergé. Le compromis est un service géré dans le chemin de confiance : une panne Parsec peut empêcher les nouvelles connexions, et le broker a visibilité sur les métadonnées de connexion sinon le contenu du flux.

La latence dans Parsec est dans la même fourchette que Moonlight quand les deux sont bien configurés. Mesurée sur le même hardware sur la même liaison, la différence visible pour l'interaction viewport 3D est faible. Les deux gèrent le scrubbing Houdini confortablement et saturent une liaison 100 Mbps en 4K 60 H.265. La différence apparaît dans la traversée NAT (Parsec est plus facile d'emblée) et dans le support hôte Linux (Sunshine est plus mature sur Linux).

Où Parsec brille : onboarding géré, traversée NAT sans VPN, contrôle d'accès centralisé, un canal de support payant. Où il est limité : la licence par siège sur une flotte s'additionne, et le broker géré est une dépendance tierce dans le chemin de connexion.

RDP traditionnel et Microsoft Remote Desktop

Le Microsoft Remote Desktop Protocol (RDP) est intégré à chaque installation Windows, a des décennies de déploiement entreprise derrière lui, et est la réponse par défaut pour les départements IT interrogés sur le bureau distant. Pour le travail 3D, la réponse est plus compliquée.

La conception originale de RDP optimisait pour la productivité bureautique — Word, Excel, Outlook, fenêtres de navigateur. Le protocole envoie des primitives graphiques (rectangles, texte, bitmaps) plutôt que des images vidéo encodées, ce qui fonctionne extrêmement bien pour du contenu statique ou changeant lentement. Pour l'édition de texte sur une workstation distante, RDP semble presque local. Pour un viewport Houdini tournant autour d'une scène procédurale à 60 fps, RDP peut s'effondrer.

Microsoft a adressé l'écart en deux phases. RemoteFX vGPU (Windows Server 2012 R2) a ajouté le streaming graphique accéléré hardware avec partage GPU, mais Microsoft l'a déprécié en 2018 en raison de vulnérabilités de sécurité et l'a complètement retiré dans Windows Server 2022. RDP 10 et plus récent a ajouté AVC444 (H.264 avec sous-échantillonnage chroma 4:4:4 complet), qui utilise l'encodeur GPU de l'hôte quand disponible et produit une qualité significativement meilleure sur le contenu en mouvement. AVC444 est la voie à suivre pour RDP accéléré GPU en 2026.

La latence sur AVC444 RDP est typiquement de 30 à 100 millisecondes de bout en bout, selon les conditions réseau et le choix d'encodeur. C'est deux à trois fois plus lent que Moonlight ou Parsec sur le même hardware. Pour le travail intensif en texte et l'édition légère d'image, l'écart n'importe pas. Pour l'interaction viewport 3D, la différence entre une réponse de 15 ms et 60 ms est la différence entre un viewport qui suit votre souris et un qui traîne derrière votre entrée.

Où RDP gagne : aucun coût de licence supplémentaire sur Windows, clients sur chaque OS majeur via Microsoft Remote Desktop, aucun logiciel tiers sur l'hôte, intégration native Active Directory et Group Policy, et une posture de sécurité connue que les équipes conformité acceptent sans question. Pour l'édition Photoshop sur workstation distante, le travail léger After Effects, la gestion de fichiers, ou l'accès à un serveur de licence Windows-only, RDP est un choix raisonnable.

Où RDP perd pour le rendu 3D : la latence est dans la mauvaise plage pour la manipulation viewport interactive, le support multi-moniteur est contraint côté client par rapport à Sunshine, la précision colorimétrique reste visiblement derrière les flux H.265 encodés NVENC, et le protocole a un long historique de CVE nécessitant une discipline de patching régulière. Nous ne déployons pas RDP comme couche de bureau distant primaire sur les nœuds de rendu GPU ; nous l'activons comme chemin d'accès secondaire pour les tâches ops qui n'ont pas besoin d'interactivité viewport.

VNC et autres alternatives

VNC (Virtual Network Computing) est la famille de protocoles qui précède la plupart de ce qui est venu après. TightVNC, TigerVNC, RealVNC et UltraVNC sont les implémentations Windows courantes ; TigerVNC et TightVNC sont le standard Linux. NoMachine NX est un fork commercial qui a substantiellement amélioré le protocole. RustDesk est le récent prétendant open source dans cet espace.

Pour le travail 3D accéléré GPU, toute la famille VNC a un désavantage structurel : la plupart des implémentations s'appuient sur l'encodage software plutôt que sur NVENC hardware, ce qui les place dans la même tranche de latence que RDP et ajoute un overhead CPU substantiel par flux. Le protocole a été conçu à la fin des années 1990 pour la productivité bureautique, et le modèle de compression frame-difference sous-jacent ne produit pas la qualité visuelle que les flux H.264 ou H.265 encodés hardware atteignent à des bitrates comparables.

NoMachine NX est l'option famille-VNC la plus solide pour le travail 3D. Le produit commercial utilise l'encodage hardware quand disponible, supporte raisonnablement la capture multi-moniteur, et tourne sur des hôtes Linux où certaines alternatives peinent. Pour les workstations GPU à hôte Linux où le support Sunshine est incomplet ou le pairing est maladroit, NoMachine peut combler le vide.

RustDesk est le projet open source qui revient souvent comme « le Parsec open source ». Le projet est véritablement impressionnant — un broker de connexion auto-hébergeable, des clients multiplateformes, et une communauté de développement active. Spécifiquement pour le travail viewport 3D accéléré GPU, nous ne l'avons pas adopté par défaut : l'intégration de l'encodeur est moins mature que la pipeline NVENC de Sunshine, et la latence et qualité mesurées en 4K 60 pour les workflows IPR-intensifs traînent derrière Moonlight + Sunshine et Parsec sur le même hardware. RustDesk convient au travail de bureau distant général ; pour la tâche spécifique du rendu 3D distant avec accélération GPU, nous ne l'avons pas adopté pour les déploiements cluster de production.

Critères de choix

Le bon protocole de bureau distant pour une charge donnée dépend de cinq facteurs, à peu près dans cet ordre d'importance pour le travail de production 3D.

Tolérance à la latence. Pour la rotation viewport 3D, la prévisualisation IPR, le scrubbing de timelines d'animation, et toute tâche interactive attendant une réponse écran en temps réel, une latence de bout en bout sous 30 ms est la zone de confort et sous 50 ms est le plafond. Au-dessus de 50 ms, le workflow semble traînant et produit une perte de productivité mesurable. Moonlight + Sunshine et Parsec livrent tous deux sous 30 ms sur des liaisons LAN ou WAN low-RTT bien configurées. RDP et VNC tendent à atterrir dans la plage 50 à 150 ms. Pour les tâches ops non interactives (inspection de logs, déplacements de fichiers, accès serveur de licence), toute latence sous 200 ms convient.

Qualité visuelle. Le travail critique en couleur (grading final dans Nuke ou Resolve, revue client archviz à l'étape finale) exige un sous-échantillonnage chroma 4:4:4, idéalement HDR-aware. RDP 10+ AVC444 supporte 4:4:4. Moonlight + Sunshine avec H.265 supporte 4:4:4 sur hardware capable. Parsec utilise par défaut 4:2:0 (encodage plus rapide, bitrate plus petit) mais supporte 4:4:4 sur le codec Warp pour les clients payants. Le travail de production 3D standard (manipulation viewport, revue IPR, lookdev) convient en 4:2:0. La validation couleur finale non.

Sécurité et contrôle d'accès. Les déploiements entreprise nécessitent authentification, audit logging et contrôle clair sur qui peut se connecter d'où. RDP s'intègre nativement avec Active Directory. Parsec Teams fournit administration centralisée avec single sign-on. Moonlight + Sunshine repose sur un modèle de pairing PIN par hôte adéquat pour les petites équipes mais qui ne passe pas à l'échelle pour le contrôle d'accès au niveau flotte sans outillage externe (ou un tunnel WireGuard agissant comme première couche d'authentification). Pour notre approche de sécurité par segmentation réseau, la couche WireGuard est le contrôle d'accès primaire et le pairing bureau distant est secondaire.

Traversée NAT. Connecter depuis le réseau domestique d'un artiste à un nœud de rendu dans un data center requiert soit un port redirigé côté data center (ce qui expose le service à l'internet ouvert), soit un tunnel VPN, soit un broker géré qui gère le NAT punching. Le broker de Parsec est le plus facile. WireGuard plus Sunshine est le plus contrôlé. La redirection de port directe sur RDP est la moins sécurisée et nous la déconseillons pour les déploiements de production.

Coût. Moonlight + Sunshine est gratuit sur toute la flotte. RDP est inclus avec Windows. Parsec est par siège (le tier Teams est significatif à l'échelle). NoMachine est par hôte. Pour un cluster GPU multi-nœuds avec accès artistes rotatif, le calcul de licence favorise l'open source plus WireGuard.

Passerelle de qualité de configuration

Avant de déclarer un setup de bureau distant apte à la production 3D, nous exécutons une batterie de huit tests sur la pile candidate. Les tests attrapent les modes de défaillance qui n'apparaissent que sous des charges spécifiques, et ils sont assez rapides (~20 minutes par hôte) pour tourner dans le cadre de la mise en service de nœuds.

Test 1 : rotation viewport sous mouvement soutenu. Ouvrez une scène Houdini ou 3ds Max modérément lourde. Faites tourner le viewport pendant 30 secondes en continu. Le frame rate au client doit tenir au-dessus de 30 fps sans saccade visible. Une saccade indique que l'encodeur étrangle ou que le jitter réseau est instable.

Test 2 : réactivité IPR. Démarrez un rendu IPR Redshift ou Karma. Modifiez un paramètre matériau, déplacez une lumière, ou bougez une caméra. Le temps entre l'entrée et la première mise à jour de pixel doit ressembler à l'interaction locale. Une latence perceptible signifie que le setup n'est pas prêt pour la production lookdev.

Test 3 : scrubbing de timeline d'animation. Scrubbez une timeline d'animation de 240 frames dans After Effects ou Houdini. Les frames cachées doivent s'afficher fluidement au client sans judder.

Test 4 : routage d'entrée multi-moniteur. Avec un hôte multi-moniteur, déplacez le curseur à travers les frontières de moniteur. Les événements de clic doivent atterrir sur le bon moniteur sans sauts de curseur entre moniteurs.

Test 5 : vérification de précision couleur. Ouvrez une référence couleur connue (charte Macbeth, scène archviz calibrée) sur hôte et client. La comparaison visuelle ne doit pas montrer de décalage couleur évident, de banding dans les gradients, ni de flou chroma visible sur le texte. Pour les workflows requérant 4:4:4, vérifiez que le mode chroma est correctement configuré.

Test 6 : sync audio (quand utilisé). Pour les workflows qui prévisualisent vidéo avec audio, jouez un clip de test sync avec un flash visible et un clic correspondant. Audio et vidéo doivent être à moins de 50 ms au client.

Test 7 : tolérance à la perte de paquets. Introduisez 1 à 2 pour cent de perte de paquets sur la liaison (tc sur Linux, Clumsy sur Windows) et répétez le Test 1. Le flux doit se dégrader gracieusement — la connexion ne doit pas crasher. Un crash sous 1 pour cent de perte indique que la configuration de retransmission du codec est erronée.

Test 8 : reconnexion après chute réseau. Désactivez la connexion réseau du client pendant 30 secondes, puis réactivez-la. La session distante doit se reconnecter automatiquement sans perdre la session utilisateur ni l'état de rendu en cours.

Tout hôte qui échoue aux Tests 1, 2, 5 ou 8 n'est pas prêt pour la production. Les Tests 3, 4, 6 et 7 sont des avertissements qui indiquent souvent un ajustement de configuration plutôt que des défaillances dures. La batterie complète tourne en moins de 30 minutes par hôte et attrape environ 90 pour cent des problèmes que nous voyons en production.

Notre choix de pile : Moonlight + Sunshine primaire, Parsec en repli

Pour les déploiements de cluster GPU dédié, notre pile de bureau distant par défaut est Moonlight + Sunshine sur WireGuard, avec Parsec en repli pour les cas spécifiques. Le raisonnement s'accumule sur plusieurs décisions.

Open source sur le chemin d'encodage. Sunshine tourne gratuitement sur la flotte GPU sans licence par nœud. NVENC est inclus dans le silicium RTX 5090 sans coût marginal. Le calcul de licence favorise de ne pas payer par siège pour un broker géré dont nous n'avons pas strictement besoin.

Modèle de sécurité unifié. Le tunnel WireGuard qui porte le trafic Moonlight est le même tunnel qui porte le trafic SMB cache, soumission de rendu, accès logs et management. Une surface de pare-feu, un jeu de clés, une procédure de rotation. Ajouter Parsec introduirait une seconde frontière de confiance (le broker Parsec) pour un service que WireGuard couvre déjà proprement.

Encodage hardware NVENC. Streamer 4K 60 fps à plusieurs clients simultanés coûte un pourcentage à un chiffre du calcul GPU sur le bloc encodeur — effectivement gratuit. Les alternatives d'encodage software consomment 20 à 40 pour cent du CPU par flux et ajoutent 30 à 100 ms de latence. Pour un nœud de rendu où CPU et GPU sont tous deux des ressources de production, le chemin d'encodage hardware est sans ambiguïté.

Clients Moonlight multiplateformes. Moonlight a des clients matures sur Windows, macOS, Linux, iOS, Android et systèmes TV. Les artistes sur différents OS desktop se connectent au même hôte Sunshine sans différences de licence par plateforme.

Parsec en repli pour cas spécifiques. Nous gardons Parsec déployé sur un sous-ensemble de nœuds pour deux scénarios : artistes dans des environnements réseau où WireGuard est bloqué ou peu fiable (rare mais réel dans certains réseaux d'entreprise avec politiques sortantes restrictives), et accès court terme de collaborateur externe où l'overhead d'onboarding WireGuard ne vaut pas la peine pour quelques heures de travail. Le chemin de repli couvre les cas limites proprement à une fraction du coût Parsec pleine flotte.

La pile est le résultat d'une analyse de compromis contre la passerelle de qualité huit-tests sur hardware réel. D'autres studios atterriront ailleurs selon priorités, topologie réseau et contraintes de conformité. Le cadre compte plus que la réponse spécifique.

FAQ

Q: Pourquoi ne pas simplement utiliser Microsoft RDP pour le rendu 3D distant ? A : RDP fonctionne bien pour la productivité bureautique mais le budget de latence du protocole (typiquement 30 à 100 ms de bout en bout) est mauvais pour le travail viewport 3D interactif, la prévisualisation IPR ou le scrubbing d'animation. Pour l'édition de texte ou la gestion de fichiers, RDP convient. Pour faire tourner une caméra Houdini à 60 fps, la latence devient apparente en quelques secondes. RDP 10+ AVC444 améliore les choses mais reste derrière Moonlight ou Parsec sur le même hardware.

Q: Moonlight est-il meilleur que Parsec pour le travail de production ? A : Ils sont techniquement comparables pour le flux vidéo — les deux utilisent H.264 ou H.265 encodé hardware sur UDP avec profils de latence similaires. Les différences sont opérationnelles : Moonlight + Sunshine est gratuit et auto-hébergé, tandis que Parsec ajoute un broker géré qui simplifie traversée NAT et onboarding à un coût par siège. Pour un cluster GPU auto-hébergé avec tunnel WireGuard déjà en place, Moonlight est le choix plus propre. Pour l'accès ad-hoc de collaborateur externe, l'onboarding géré de Parsec vaut le coût.

Q: Plusieurs artistes peuvent-ils se connecter simultanément au même nœud de rendu ? A : Sunshine supporte plusieurs sessions concurrentes sur un seul hôte avec comptes utilisateur séparés, mais pour le travail 3D GPU-lié c'est habituellement impraticable — deux artistes lançant Redshift IPR sur le même nœud se concurrenceront pour VRAM et calcul. Le pattern courant sur clusters dédiés est un artiste par nœud pendant les sessions interactives, avec les mêmes nœuds rejoignant la file de rendu quand aucune session interactive n'est active. Pour les sessions de revue partagée, Parsec supporte un mode observer où des utilisateurs additionnels peuvent regarder une session sans prendre le contrôle des entrées.

Q: Qu'en est-il des clients iPad ou iPhone pour le travail distant ? A : Moonlight a un client iOS mature (Moonlight Game Streaming sur l'App Store) et un client Android, tous deux se connectant aux hôtes Sunshine sans différences de configuration par rapport à l'expérience desktop. Pour les producteurs ou directors revoyant une prévisualisation de rendu depuis une tablette pendant une réunion, cela fonctionne bien. Les contrôles tactiles conviennent à la navigation plutôt qu'à la modélisation précise, mais pour les workflows de revue et d'approbation les clients mobiles sont un vrai outil de productivité.

Q: Comment l'audio est-il géré dans les sessions de rendu distant ? A : Sunshine capture l'audio système et l'envoie via le même flux UDP que la vidéo, avec synchronisation gérée par le protocole. La qualité audio est suffisamment haute pour prévisualiser des compositions motion graphics avec leur mix audio final, et le sync est généralement dans les 50 ms — bien sous le seuil perceptif pour la revue vidéo. Pour le travail audio-critique (sound design, mixage), l'audio local reste le bon choix. Parsec gère l'audio similairement.

Q: Qu'en est-il du travail critique en couleur où la chroma 4:4:4 importe ? A : Le sous-échantillonnage chroma 4:4:4 préserve la pleine résolution couleur plutôt que la réduction 4:2:0 utilisée par la plupart des codecs vidéo grand public, et il compte pour le grading couleur final et la validation client archviz où les décalages couleur subtils sont visibles. Moonlight + Sunshine avec H.265 supporte 4:4:4 sur hardware capable. RDP 10+ AVC444 est nommé pour cette fonctionnalité et la supporte nativement. Le codec Warp de Parsec supporte 4:4:4 pour les clients payants. Pour le lookdev et le travail viewport qui n'est pas l'étape de validation couleur finale, 4:2:0 est acceptable et utilise significativement moins de bande passante.