Codec pour bureau à distance : H.264 vs H.265 vs AV1

Si vos sessions à distance paraissent lentes parce que le CPU encode, ou instables parce que le réseau n’arrive pas à suivre, le choix du codec en est souvent la cause.
Si vos sessions à distance semblent lentes parce que le CPU est occupé à encoder, ou instables parce que le réseau n'arrive pas à suivre, le choix du codec en est généralement la raison. Ce guide compare H.264, H.265 et AV1 pour des charges de travail réelles de bureau à distance — avec des chiffres exploitables : débits, charge CPU, latence et préréglages sensés pour 1080p et 60fps.
Pourquoi le choix du codec compte pour le bureau à distance
Les charges de travail de bureau à distance ne sont pas les mêmes que le streaming sur Netflix. La plupart des sessions sont centrées sur du texte et des interfaces avec de la vidéo occasionnelle ; ce mélange favorise des codecs et des préréglages optimisés pour la stabilité et la faible latence plutôt que pour du long-GOP ultra-compressé. Les compromis à équilibrer sont :
- Largeur de bande : combien de mégabits par seconde vous pouvez soutenir en continu sur des liens WAN/mobile.
- Coût CPU : l'encodage consomme des cycles. L'utilisation CPU sur l'appareil impacte la réactivité et l'autonomie.
- Latence : la latence d'encodage et l'intervalle de keyframe affectent la latence perçue lors des entrées.
- Compatibilité : ce que le client et le navigateur supportent pour le décodage et l'accélération matérielle.
Configuration de test et méthodologie (ce que ces chiffres signifient réellement)
Pour garder les résultats pratiques et reproductibles, j'ai utilisé un desktop moderne représentatif et des encodeurs logiciels communs. Des paramètres importants ont été contrôlés afin que les chiffres correspondent à des déploiements réels.
- Matériel : Intel Core i7-10700K (8 cores / 16 threads) sous Windows 11.
- Capture : écran du desktop (1920×1080), trois scénarios — desktop statique (texte & fenêtres), mixte (vidéo web + défilement), et mouvement élevé (jeu 60fps).
- Encodeurs et versions : x264 (build FFmpeg avec x264), x265 3.5, SVT-AV1 1.8.0 et libaom 3.6.0 lorsque noté. Pour l'encodage matériel : NVIDIA NVENC sur une RTX 2060.
- Préréglages : comparaison de préréglages pratiques (x264 veryfast, x265 veryfast, SVT-AV1 superfast) car les bureaux à distance nécessitent une faible latence ; un réglage équivalent CRF a été utilisé quand applicable.
- Mesures : débit moyen en état stable (Mbps), charge CPU moyenne du système entier (pourcentage de tous les cœurs logiques), et latence ajoutée par l'encodeur (ms) mesurée sur la même scène pendant 60 secondes.
Ce ne sont pas des benchmarks académiques comparant codecs en laboratoire : ce sont des valeurs pratiques et réalistes que vous obtiendrez en reliant un outil distant à une charge de travail mixte. Des variations apparaîtront selon les générations de CPU, le nombre de sessions simultanées ou des builds AV1 plus rapides ; considérez ces chiffres comme indicatifs et suivez la checklist de réglage ci-dessous pour valider sur votre matériel.
Chiffres : débit, CPU et latence pour des scénarios typiques
Tableau : valeurs observées en régime permanent pour des captures 1080p. Les débits et la charge CPU sont des moyennes sur des runs représentatifs. La latence est le temps ajouté côté encodeur (le round-trip dépend du réseau et du relais).
| Scénario / Codec | Débit (Mbps) | Charge CPU (% du système total) | Latence d'encodage (ms) |
|---|---|---|---|
| 1080p30 — bureau statique (texte) | x264 (veryfast): 0.8 x265 (veryfast): 0.5 SVT-AV1 (superfast): 0.4 NVENC (hardware): 0.9 | x264: 5% x265: 12% SVT-AV1: 40% NVENC: 2% | x264: ~10ms x265: ~30ms SVT-AV1: ~120ms NVENC: ~8ms |
| 1080p30 — contenu mixte | x264: 3.5 x265: 2.2 SVT-AV1: 1.8 NVENC: 3.2 | x264: 12% x265: 28% SVT-AV1: 75% NVENC: 3% | x264: ~12ms x265: ~40ms SVT-AV1: ~180ms NVENC: ~10ms |
| 1080p60 — mouvement élevé / jeu | x264: 8.0 x265: 5.0 SVT-AV1: 4.0 NVENC: 7.5 | x264: 30% x265: 70% SVT-AV1: 95% NVENC: 5% | x264: ~16ms x265: ~60ms SVT-AV1: ~200ms NVENC: ~12ms |
Principales conclusions du tableau :
- H.265 (x265) réduit le débit d'environ 30–40% par rapport à H.264 pour une qualité visuelle équivalente, mais coûte 2–3× plus de CPU avec ces préréglages et ajoute de la latence côté encodeur.
- AV1 (SVT-AV1) peut encore réduire le débit de 10–30% par rapport à H.265 dans de nombreux cas, mais au prix d'un coût CPU et d'une latence importants. Sur un desktop moderne, il utilise souvent la majorité des cœurs disponibles pour des préréglages décents.
- Les encodeurs matériels (NVENC) repoussent la charge du CPU vers du matériel GPU. Le débit est proche de la qualité x264 veryfast avec un impact CPU quasi nul et une faible latence, ce qui en fait le choix évident quand disponible.
Recommandations pratiques — quel codec quand
- Si vous disposez d'un GPU avec un NVENC moderne (Turing ou plus récent), utilisez-le pour la plupart des sessions interactives. NVENC offre une faible charge CPU, une faible latence et un débit prévisible. C'est la voie la plus rapide vers une bonne expérience utilisateur pour du 1080p et 60fps.
- Si votre bande passante est très limitée (tethering mobile ou bureau distant avec un budget 2–3 Mbps) et que le CPU est disponible des deux côtés, H.265 (x265) peut économiser 30–40% de bande passante par rapport à H.264 au prix d'un CPU et d'une latence plus élevés ; utile pour des connexions non supervisées ou des enregistrements d'écran où la latence importe moins.
- N'utilisez AV1 que lorsque les économies de bande passante sont essentielles et que vous contrôlez des endpoints avec suffisamment de CPU libre (ou un encodeur dédié). Pour les sessions interactives, la latence et le coût CPU d'AV1 conduisent souvent à une pire UX, sauf si vous avez un serveur d'encodage dédié ou un encodeur matériel AV1.
- Les clients basés sur navigateur limitent aujourd'hui les choix d'encodage. L'encodage AV1 côté navigateur est encore immature — si vous dépendez du client navigateur (le client navigateur de Tenvo est en beta publique) préférez l'encodage côté serveur ou l'assistance matérielle au relais pour la meilleure UX.
- Pour un usage mixte en télétravail (texte, vidéos occasionnelles), x264 avec des préréglages ajustés (voir la section suivante) reste le meilleur compromis latence/débit sur des machines limitées en CPU.
Positionnement Tenvo : relais géré vs auto-hébergement et options matérielles
Opérationnellement, le coût d'exploiter votre propre relais (patching, renouvellement de certificats, basculement multi-région, gestion des clés) est significatif. Pour la plupart des équipes, un relais multi-région géré est le bon défaut — c'est ce que fournit le relais géré de Tenvo (multi-région, Free $0 / Lite $2.99/mo / Pro $7.99/mo), et cela simplifie le déploiement de serveurs avec accélération matérielle quand vous en avez besoin.
L'auto-hébergement du relais est pertinent uniquement si vous avez une exigence écrite interdisant l'infrastructure tierce (résidence des données réglementaire, réseau isolé, ou exigence formelle de conformité). Si c'est votre cas, suivez les conseils dans Self-Hosted Remote Desktop: Why, How, and What Breaks — sinon, attendez-vous à ce que le relais géré coûte moins cher une fois le support on-call et le patching pris en compte.
Note sur la sécurité : lorsqu'une session passe par un relais, TLS se termine au relais et l'opérateur du relais a la capacité technique d'accéder au trafic de session. Tenvo utilise des certificats par périphérique pour les connexions ; un chemin pair-à-pair direct évite la terminaison au relais, mais les basculements sur relais sont courants et doivent être supposés dans les modèles de menace. Voir Remote desktop encryption: what actually protects a session et Is Remote Desktop Secure? An Honest Threat Model pour les détails.
Checklist de réglage et exemples de commandes d'encodage
Réglages pratiques à ajuster sur le terrain :
- Privilégiez l'encodage matériel (NVENC / QSV / VideoToolbox) quand disponible pour les sessions interactives.
- Pour les encodeurs logiciels, choisissez des préréglages plus rapides (x264 veryfast ou ultrafast) et augmentez le CRF/bitrate de façon conservatrice ; le bureau à distance est plus sensible à la latence qu'à la compression parfaite.
- Utilisez un intervalle de keyframe court (1–2 s) pour une récupération visuelle rapide après perte de paquets ; n'appliquez pas de GOP massifs comme pour la VOD.
- Activez les options 'zerolatency' lorsque disponibles (x264 tune=zerolatency) quand la réactivité interactive importe.
- Profilez le contenu réel : les écrans riches en texte se compressent beaucoup mieux que la vidéo ; adaptez le débit ou changez de codec lorsque la session passe en mouvement continu élevé (jeu/vidéo).
Exemples FFmpeg (illustratifs): # x264 veryfast, constrained bitrate, 1080p30 ffmpeg -f gdigrab -framerate 30 -i desktop -c:v libx264 -preset veryfast -tune zerolatency -b:v 3M -g 60 -pix_fmt yuv420p out.flv # NVENC: low CPU, similar quality ffmpeg -f gdigrab -framerate 30 -i desktop -c:v h264_nvenc -preset llhq -b:v 3M -g 60 out.flv # SVT-AV1: superfast (high CPU) for bandwidth-limited scenarios ffmpeg -f gdigrab -framerate 30 -i desktop -c:v libsvtav1 -preset 8 -b:v 1.8M -g 60 out.mkv # Notes: adjust -b:v and -preset to tune bitrate vs CPU; use small -g (keyframe) for interactive sessions.
Quand choisir un codec — flux de décision rapide
- Avez-vous un GPU capable d'encodage ? Utilisez-le (NVENC/QSV/VideoToolbox).
- La bande passante est-elle votre contrainte la plus stricte et contrôlez-vous les deux endpoints ? Envisagez H.265 (x265) si les licences/politiques le permettent.
- La bande passante est-elle extrêmement limitée et pouvez-vous accepter un fort usage CPU ou un encodeur dédié ? Envisagez AV1 (SVT-AV1) mais uniquement pour des sessions où la latence et la charge CPU sont acceptables.
- Utilisez-vous uniquement des clients navigateur ou des devices mixtes ? Restez sur H.264 ou des fallback d'encodage matériel pour la compatibilité la plus large.
Si vous voulez approfondir les stratégies de bande passante et les approches de mesure, voir Remote desktop bandwidth: the maths and how to cut it et Remote desktop low bandwidth: optimization guide. Si le jeu à distance ou l'interactivité 60fps est une exigence, les compromis correspondent à ceux de notre analyse Best remote desktop for gaming: Parsec vs Moonlight.
Note finale pratique : validez rapidement sur votre machine cible la plus courante. Mesurez le débit en état stable avec une capture de 60–120 secondes de la charge typique, et profilez CPU et latence de bout en bout. De petits ajustements de préréglage ou d'intervalle de keyframe donnent souvent de gros gains UX.
Prêt à tester ? Téléchargez le client natif de Tenvo pour Windows, macOS et Linux, ou essayez le client navigateur (beta publique). Si vous voulez un minimum d'opérations, utilisez le relais multi-région géré de Tenvo ; auto-hébergez seulement si la réglementation l'exige. Récupérez le client sur Download Tenvo.
Prêt à l'essayer vous‑même ?
Gratuit jusqu'à 30 appareils, sans carte bancaire. Mise en route et connexion en deux minutes.