Remio wird von einem kleinen Team in aller Öffentlichkeit gebaut. Dies ist das Arbeitsprotokoll — Aufnahmepfade, die wir auseinandergenommen haben, Encoder-Einstellungen, die uns überrascht haben, Latenzbudgets, die wir gesprengt und neu aufgebaut haben. Neuere Einträge stehen oben; ältere bleiben, wie geschrieben, auch wenn wir inzwischen unsere Meinung geändert haben.
Zuletzt aktualisiert am 19.05.20267 EinträgeChronologisch, die neuesten zuerst
✦Forschungsnotizen
Das technische Protokoll, der Reihe nach.
Jeder Eintrag ist datiert, mit Status versehen und in sich geschlossen. Ausgeliefert bedeutet, dass die Änderung im neuesten Build live ist, Experiment bedeutet, dass wir noch messen, und archiviert bedeutet, dass wir weitergezogen sind.
Ausgeliefert
Die virtuelle Anzeige folgt jetzt dem Client-Fenster.
Wochenlang hielt der macOS-Host seine virtuelle Anzeige fest auf der Bildschirmauflösung des Clients, was bedeutete, dass sich Host-Mauszeiger und Client-Mauszeiger über die Größe uneinig waren, sobald sich eine von beiden änderte. Wir haben die Verwaltung der virtuellen Anzeige neu geschrieben, sodass der Arbeitsbereich des Hosts der Zeichenfläche des Client-Fensters in Echtzeit folgt. Die Mauszeigergrößen stimmen nun über die Grenze hinweg bei jeder Fenstergröße überein, so wie sich die Bildschirmfreigabe von Apple schon immer verhalten hat.
logische Punkte der virtuellen Anzeige ≡ Punkte der Zeichenfläche des Client-Fensters · Pixelbegrenzung 3840 · Retina 1× oder 2×, je nach nativem Pixelrahmen des Fensters gewählt
Experiment
Warum wir den Rahmen der virtuellen Anzeige auf 3840 Pixel begrenzt haben.
Das interne macOS-Framework, das Anzeigemodi für virtuelle Anzeigen baut, hat ein leise zerstörerisches Verhalten: Erhält es eine maximale Abmessung von 4096 oder mehr, erfindet es am Maximum einen Phantom-Retina-Modus mit 2× und stiehlt das Aktiv-Flag. Die angeforderte Pixelzahl verdoppelt sich. Das haben wir über vier Nächte Probe-und-Protokoll empirisch bestätigt. Dreitausendachthundertvierzig passt für jedes Retina-MacBook im Vollbild plus einen externen 4K-Monitor, und das Framework hört auf zu synthetisieren. Den langen Schwanz beobachten wir weiter.
empirischer Defekt bei ≥ 4096 · Obergrenze = 3840 · deckt MacBook Pro 16″ Retina (3456 × 2234) und externen 4K-Monitor (3840 × 2160) ab
Ausgeliefert
Rückkehr zum vorherigen Build der Streaming-Engine nach einem einwöchigen Experiment.
Wir haben unsere Streaming-Engine gegen einen neueren Zweig neu gebaut, in der Hoffnung, dass die aktualisierte Taktlogik auf dem Pfad im lokalen Netzwerk ein paar Millisekunden freisetzt. Stattdessen verschlechterte sich der Empfangspuffer bei jeder gemessenen Remote-Sitzung: Der Median Ende-zu-Ende stieg um 18 ms, und die Streuung wurde breiter. Wir sind auf iOS, macOS, Android und Windows zum stabilen Build zurückgekehrt. Die Patches des neuen Zweigs sind archiviert, falls sich das Upstream-Verhalten ändert.
Median-Latenz des neuen Builds · 64 ms remote · Median des vorherigen Builds · 46 ms remote · Tuning-Flags unverändert
Ausgeliefert
Adaptive Erkennung der Bitrate für lokales Netzwerk gegenüber Remote ab dem ersten Umlaufzeit-Messwert.
Der Host wartet nun nach dem Verbindungsaufbau auf die erste Messung der Umlaufzeit und wählt dann einen von zwei Bitraten-Rahmen. Unter 15 ms gilt die Verbindung als direkt im lokalen Netzwerk: Start 8 Mbps, Minimum 8 Mbps, Maximum 30 Mbps. Über 15 ms gilt sie als über Relay oder entfernt: Start 2 Mbps, Minimum 300 Kbps, Maximum 15 Mbps. Die Schwelle liegt zwischen WLAN im selben Netzwerk und jedem plausiblen Mobilfunk- oder regionsübergreifenden Relay, daher waren Fehlalarme in der Beta-Telemetrie selten.
lokal direkt · 1 – 5 ms · WLAN im selben Netz · 5 – 10 ms · regionales Relay · 30 – 80 ms · 4G · 40 – 100 ms
Ausgeliefert
Hardware-H.265 auf AMD als primärer Encoder des Windows-Hosts.
Nach einem langen Wettstreit mit konkurrierenden Encodern gewann Hardware-H.265 auf AMD jeden Benchmark des Windows-Hosts, der uns wichtig war: niedrigere mittlere Kodierzeit, niedrigere Keyframe-Spitze, und die Voreinstellung mit extrem niedriger Latenz und konstanter Bitrate verhält sich unter Pufferdruck vorhersagbar. H.264 bleibt als Rückfall, wenn die GPU anderer Meinung ist. B-Frames sind aus. Das Low-Delay-Flag ist an. Der Encoder gibt pro Aufnahmetakt immer genau ein Bild aus.
Warum wir aufgehört haben, Bilder überhaupt zu puffern.
Ein Remote Desktop ist kein Videoanruf. Jedes Bild ist der neueste Bildschirmzustand. Ein altes Bild ist per Definition eine Lüge. Wir haben den Empfangspfad so neu gebaut, dass es keinen Wiedergabepuffer gibt: Ein Bild kommt an, es wird dekodiert, es wird dargestellt, in dieser Reihenfolge, im selben Bildintervall. Verlorene Bilder fordern einen frischen Keyframe an statt einer erneuten Übertragung des alten. Wir akzeptieren das gelegentliche kurze Einfrieren. Wir akzeptieren nicht die stetige Millisekunden-Steuer einer Warteschlange.
erzwungene Wiedergabeverzögerung · min 0 / max 0 · minimale Wiedergabeverzögerung · 0 · Keyframe-Anforderung bei Verlust · keine erneute Paketübertragung
Archiviert
Das Latenzbudget, zum ersten Mal aufgeschrieben.
Wir saßen in einem Raum und arbeiteten rückwärts von der Zahl, die Nutzer spüren sollten — unter zwanzig Millisekunden, von Glas zu Glas, in einer typischen Sitzung im lokalen Netzwerk. Aufnahme, Kodierung, Taktung, Senden, Empfangspuffer, Dekodierung, Darstellung. Wir schrieben jeden Schritt auf und gaben ihm ein Millisekundenbudget, an dem wir messen konnten. Die meisten Einträge in diesem Protokoll stammen daraus, diese Zahlen im Produktivverkehr zu verteidigen.
Aufnahme · 1 ms · Kodierung · 3 ms · Burst der Taktung · ≤ 10 ms · Empfangspuffer · 0 ms · Dekodierung · 2 ms · Darstellung · 1 ms
✦Signalrahmen
Was wir messen, Sitzung für Sitzung.
Diese vier Zahlen stehen in jeder Versionsnotiz, weil sie beschreiben, wie sich die Verbindung tatsächlich anfühlt — nicht, was sie auf einem Datenblatt behauptet.
Streaming-Auflösung
Bis zu 6Knativer Pixelrahmen, Retina 1× oder 2× je nach Fenster gewählt
Bildrate
Bis zu 120 fpsfester Takt, B-Frames deaktiviert, ein Aufnahmetakt pro Bild
Verarbeitungslatenz, lokales Netzwerk
~8 msintern gemessen auf einer direkten Verbindung von Gerät zu Gerät — der Rest ist der eigene 60-Hz-Bildwiederholtakt Ihres Displays
Transportverschlüsselung
Ende-zu-EndeEnde-zu-Ende-Verschlüsselung mit jedes Mal einem frischen Sitzungsschlüssel
Das Lab wird aktualisiert, wenn etwas landet oder etwas kaputtgeht. Wenn das nützlicher klingt als ein vierteljährlicher Newsletter, ist der Download-Link nur einen Klick entfernt — und das Sicherheits-Whitepaper für die lange Version ebenso.
