Remio est construit en public par une petite équipe. Voici le journal de travail — des chemins de capture que nous avons démontés, des réglages d’encodeur qui nous ont surpris, des budgets de latence que nous avons explosés puis reconstruits. Les entrées les plus récentes sont en haut ; les plus anciennes restent telles qu’écrites, même quand nous avons changé d’avis depuis.
Dernière mise à jour le 19 mai 20267 entréesChronologique, la plus récente d’abord
✦Notes de recherche
Le journal d’ingénierie, dans l’ordre.
Chaque entrée est datée, a un statut et se suffit à elle-même. Livré signifie que le changement est en production dans la dernière version, expérience signifie que nous mesurons encore, et archivé signifie que nous sommes passés à autre chose.
Livré
L’écran virtuel suit désormais la fenêtre du client.
Pendant des semaines, l’hôte macOS a gardé son écran virtuel fixé à la résolution de l’écran du client, ce qui voulait dire que le curseur de l’hôte et celui du client n’étaient pas d’accord sur la taille dès que l’un ou l’autre changeait. Nous avons réécrit le gestionnaire d’écran virtuel pour que l’espace de travail de l’hôte suive en temps réel le canevas de la fenêtre du client. La taille des curseurs correspond désormais de part et d’autre de la frontière, quelle que soit la taille de la fenêtre, comme le Partage d’écran d’Apple l’a toujours fait.
points logiques de l’écran virtuel ≡ points du canevas de la fenêtre du client · limite de pixels 3840 · Retina 1× ou 2× choisi selon l’enveloppe de pixels natifs de la fenêtre
Expérience
Pourquoi nous avons plafonné l’enveloppe de l’écran virtuel à 3840 pixels.
Le framework interne de macOS qui construit les modes d’affichage des écrans virtuels a un comportement discrètement destructeur : quand on lui donne une dimension maximale de 4096 ou plus, il invente un mode Retina 2× fantôme au maximum et vole l’indicateur actif. Le nombre de pixels demandé double. Nous l’avons confirmé empiriquement sur quatre nuits de sondage et de journalisation. Trois mille huit cent quarante tient un plein écran de n’importe quel MacBook Retina plus un écran externe 4K, et le framework cesse de synthétiser. Nous surveillons toujours la longue traîne.
casse constatée empiriquement à ≥ 4096 · plafond = 3840 · couvre le MacBook Pro 16″ Retina (3456 × 2234) et un écran externe 4K (3840 × 2160)
Livré
Retour à la version précédente du moteur de diffusion après une semaine d’expérience.
Nous avions reconstruit notre moteur de diffusion sur une branche plus récente en espérant que la logique de cadencement mise à jour gagnerait quelques millisecondes sur le chemin du réseau local. Au lieu de cela, le tampon de réception a régressé sur chaque session distante que nous avons mesurée : la médiane de bout en bout a grimpé de 18 ms et la variance s’est élargie. Nous sommes revenus à la version stable sur iOS, macOS, Android et Windows. Les correctifs de la nouvelle branche sont archivés au cas où le comportement en amont changerait.
latence médiane de la nouvelle version · 64 ms à distance · médiane de la version précédente · 46 ms à distance · indicateurs de réglage inchangés
Livré
Détection adaptative du débit réseau local ou distant dès le premier échantillon d’aller-retour.
L’hôte attend désormais la première mesure du temps d’aller-retour une fois la connexion établie, puis choisit l’une de deux enveloppes de débit. En dessous de 15 ms, la connexion est traitée comme directe sur réseau local : départ à 8 Mbps, minimum 8 Mbps, maximum 30 Mbps. Au-dessus de 15 ms, elle est traitée comme relayée ou distante : départ à 2 Mbps, minimum 300 Kbps, maximum 15 Mbps. Le seuil se situe entre le Wi-Fi du même réseau et tout relais cellulaire ou interrégional plausible, donc les faux positifs ont été rares dans la télémétrie de la bêta.
direct en réseau local · 1 – 5 ms · Wi-Fi du même réseau · 5 – 10 ms · relais régional · 30 – 80 ms · 4G · 40 – 100 ms
Livré
Le H.265 matériel sur AMD comme encodeur principal de l’hôte Windows.
Après un long duel contre des encodeurs concurrents, le H.265 matériel sur AMD a remporté tous les benchmarks de l’hôte Windows qui nous importaient : temps d’encodage médian plus faible, pic d’image clé plus faible, et le préréglage à débit constant ultra-faible latence se comporte de façon prévisible sous pression de tampon. Le H.264 reste en repli quand le GPU n’est pas d’accord. Les images B sont désactivées. L’indicateur de faible délai est activé. L’encodeur émet toujours exactement une image par cycle de capture.
Pourquoi nous avons arrêté de mettre des images en tampon, tout simplement.
Un bureau à distance n’est pas un appel vidéo. Chaque image est l’état le plus récent de l’écran. Une image ancienne est, par définition, un mensonge. Nous avons reconstruit le chemin de réception pour qu’il n’y ait aucun tampon de lecture : une image arrive, elle est décodée, elle est rendue, dans cet ordre, sur le même intervalle d’image. Les images perdues demandent une nouvelle image clé plutôt qu’une retransmission de l’ancienne. Nous acceptons un bref gel occasionnel. Nous n’acceptons pas la taxe constante de quelques millisecondes d’une file d’attente.
délai de lecture forcé · min 0 / max 0 · délai de lecture minimal · 0 · demande d’image clé en cas de perte · aucune retransmission de paquets
Archivé
Le budget de latence, mis par écrit pour la première fois.
Nous nous sommes assis dans une salle et avons raisonné à rebours à partir du chiffre que nous voulions faire ressentir aux utilisateurs — moins de vingt millisecondes, de verre à verre, sur une session type en réseau local. Capture, encodage, cadencement, envoi, tampon de réception, décodage, rendu. Nous avons noté chacun et lui avons donné un budget en millisecondes que nous pouvions mesurer. La plupart des entrées de ce journal viennent de la défense de ces chiffres sur du trafic en production.
capture · 1 ms · encodage · 3 ms · rafale de cadencement · ≤ 10 ms · tampon de réception · 0 ms · décodage · 2 ms · rendu · 1 ms
✦Enveloppe du signal
Ce que nous mesurons, session après session.
Ces quatre chiffres figurent dans chaque note de version parce qu’ils décrivent ce que la connexion donne réellement — pas ce qu’elle prétend sur une fiche technique.
Résolution du flux
Jusqu’à 6Kenveloppe de pixels natifs, Retina 1× ou 2× choisi selon la fenêtre
Fréquence d’images
Jusqu’à 120 fpscadence fixe, images B désactivées, un cycle de capture par image
Latence de traitement, réseau local
~8 msmesurée en interne sur une connexion directe d’appareil à appareil — le reste correspond à la cadence de rafraîchissement de 60 Hz de votre propre écran
Chiffrement du transport
De bout en boutchiffrement de bout en bout avec une nouvelle clé de session à chaque fois
Le lab se met à jour quand quelque chose aboutit ou casse. Si cela vous paraît plus utile qu’une newsletter trimestrielle, le lien de téléchargement est à un clic — tout comme le livre blanc de sécurité pour la version longue.
