Comment nous avons rendu le partage d'écran quatre fois plus rapide

La latence du partage d'écran fait partie de ces problèmes qu'on ne remarque que lorsqu'ils deviennent gênants. Un présentateur passe à la diapositive suivante, et la salle qui regarde l'écran partagé la voit avec un temps et demi de retard. Rien de cassé à proprement parler, juste un décalage. Au fil de plusieurs versions, nous avons examiné de près l'origine de ce délai dans le partage d'écran de Cliqer et ramené la latence permanente de plus de deux secondes à environ une demi-seconde, soit une amélioration d'environ quatre fois. Voici comment, en termes simples.

Nous n'allons pas nous cacher derrière des noms de code ni prétendre qu'il existait une solution miracle unique. Il y a eu trois corrections distinctes, chacune visant un endroit différent où se cachait le délai, et leurs effets se sont cumulés.

Pourquoi le partage d'écran prend du retard

Lorsque vous partagez un écran, trois choses doivent se produire avant qu'un spectateur voie une image : votre machine doit la capturer, l'encoder en vidéo et l'envoyer. Chacune de ces étapes peut ajouter discrètement du délai, et l'effet se cumule. Un encodeur lent, plus un tampon prudent, plus l'attente de la prochaine image complète peuvent facilement totaliser deux ou trois secondes, même sur une connexion rapide.

Le plus délicat, c'est qu'aucune de ces étapes ne semble défaillante prise isolément. La capture fonctionne. L'encodage fonctionne. Le flux arrive. Il est simplement en retard, et un « simple retard » est difficile à diagnostiquer sans mesurer chaque étape séparément.

Correction n° 1 : ne plus encoder deux fois la même image

La première source de délai était du travail inutile. Les partages d'écran et NDI étaient encodés deux fois en coulisses, une fois pour chaque chemin de sortie, et une diapositive fixe était réencodée en continu alors que rien n'avait changé à l'écran. Cela doublait la charge de l'encodeur sans aucun bénéfice visuel, et le pipeline était toujours plus occupé que nécessaire, ce qui repoussait chaque image plus loin dans la file d'attente.

Supprimer la passe d'encodage en double, et ne plus réencoder lorsque l'image n'a pas changé, a immédiatement libéré une marge processeur appréciable. Moins de contention sur l'encodeur signifie que chaque image qui doit réellement être encodée est traitée plus tôt.

Correction n° 2 : resserrer le tampon sans perdre en résilience

La deuxième source était le tampon situé entre l'encodeur et le réseau, l'élément qui sert à absorber les brefs aléas du réseau pour qu'une saccade sur la ligne ne se transforme pas en saccade à l'écran. Ce type de tampon est par nature un compromis : trop petit, le moindre incident provoque des défauts visibles ; trop généreux, vous ajoutez du délai à chaque image, au cas où quelque chose tournerait mal plus tard.

Le tampon avait été dimensionné généreusement, ce qui ajoutait du délai à chaque image dans le cas courant pour se protéger d'un cas rare. Le resserrer a réduit le retard dans le pire des cas de quelques secondes à bien moins d'une seconde, tout en absorbant toujours les brefs aléas du réseau sans défauts visibles. C'est le genre de correction qui ressemble à un simple changement de chiffre dans un diff, mais qui relève en réalité d'un arbitrage sur le mode de défaillance que l'on préfère subir.

Correction n° 3 : ne plus faire attendre la prochaine image clé aux nouveaux spectateurs

La troisième correction ciblait un moment précis et pénible : ce qui se passe quand quelqu'un rejoint un partage déjà en cours. La compression vidéo fonctionne en n'envoyant qu'occasionnellement des images complètes, appelées images clés, avec entre elles des images plus légères qui indiquent « ce qui a changé depuis la dernière fois ». Un spectateur qui arrive en cours de flux ne peut pas interpréter ces images intermédiaires tant qu'il n'a pas reçu d'image clé sur laquelle s'appuyer, ce qui l'obligeait auparavant à attendre la prochaine image clé programmée, jusqu'à trois secondes plus tard.

La solution a consisté à garder en cache l'image clé la plus récente et à la transmettre à un nouvel abonné dès qu'il se connecte, au lieu de le faire attendre la prochaine image clé programmée. Grâce à cela, combiné à la cadence d'images par intervalles décrite dans notre documentation sur le partage d'écran, les nouveaux spectateurs voient désormais la vidéo quelques millisecondes après avoir rejoint un partage, au lieu d'attendre jusqu'à trois secondes la prochaine image clé.

Cumulez les trois corrections, et la latence permanente de plus de deux secondes, à laquelle la plupart des gens ne se sont jamais vraiment fiés, est devenue environ une demi-seconde, soit une amélioration d'environ quatre fois, tout en consommant moins de processeur et de bande passante qu'auparavant. La pleine fréquence d'images compte aussi : la vidéo de programme était discrètement plafonnée à environ 31 images par seconde quelle que soit la source, si bien qu'un partage à 60 i/s s'affiche désormais aussi fluide côté réception que sur l'écran du présentateur.

Ce que cela change si vous présentez dès maintenant

Rien de tout cela ne vous oblige à modifier un réglage. C'est intégré au pipeline de partage d'écran de l'application de bureau, et cela s'applique que vous partagiez un seul écran dans une petite salle ou que vous meniez une production Studio complète avec plusieurs sources, y compris des workflows vMix qui reposent sur un flux rapide et prévisible. Dans Cliqer 3, la vidéo de Studio sur Mac est zéro copie : les images de la caméra, les sources et le Program restent dans la mémoire du GPU, et l'encodeur matériel lit le Program directement depuis la surface GPU. Cliqer 3 affiche aussi en permanence la fréquence d'images du Program ainsi que la charge GPU et processeur dans la ligne d'état de Studio, pour que vous puissiez vérifier vous-même la fréquence d'images en plein spectacle. Si vous voulez ajuster la qualité par rapport à la bande passante en plus du travail sur la latence, les réglages du partage d'écran couvrent le choix du codec, la résolution et le débit, et la version de bureau 2.2.0 a ajouté la possibilité d'inclure directement l'audio système ou du microphone dans un partage.

Pour les configurations hybrides où le délai était le plus visible, notamment lorsqu'un intervenant à distance regarde un écran partagé et réagit en direct, cet article complète notre guide pour corriger la latence du partage d'écran en réunion hybride et notre explication sur la latence de la télécommande de présentation en millisecondes, qui compte tout autant côté contrôle que côté vidéo.

Où passe le reste de la latence

Le partage d'écran n'est qu'une partie du trajet. L'autre est le chemin réseau lui-même : la connexion entre présentateur et spectateur est-elle directe ou relayée, et que se passe-t-il sur les réseaux qui bloquent le trafic pair à pair direct ? Nous traitons cet aspect, y compris la raison pour laquelle cette latence ne peut jamais être totalement éliminée sur certains réseaux, dans Les serveurs TURN expliqués et WebRTC est-il sécurisé ?.

FAQ

Essayez par vous-même

Le moyen le plus rapide de sentir la différence est de partager un écran et d'observer le visage de quelqu'un au moment où il le voit. Téléchargez Cliqer gratuitement et essayez un partage d'écran sur votre propre installation, ou découvrez toutes les fonctionnalités du partage d'écran et comparez les offres sur la page tarifs.