Remio è costruito in pubblico da un piccolo team. Questo è il registro di lavoro: percorsi di acquisizione che abbiamo smontato, impostazioni dei codificatori che ci hanno sorpreso, budget di latenza che abbiamo sforato e ricostruito. Le voci più recenti sono in alto; quelle più vecchie restano com'erano scritte, anche quando nel frattempo abbiamo cambiato idea.
Ultimo aggiornamento 2026-05-197 vociIn ordine cronologico, le più recenti per prime
✦Note di ricerca
Il registro di ingegneria, in ordine.
Ogni voce è datata, con il suo stato, e autonoma. Rilasciato significa che la modifica è attiva nell'ultima versione, esperimento significa che stiamo ancora misurando e archiviato significa che siamo passati oltre.
Rilasciato
Lo schermo virtuale ora segue la finestra del client.
Per settimane l'host macOS ha tenuto il suo schermo virtuale fisso alla risoluzione dello schermo del client, il che significava che il cursore dell'host e quello del client non erano d'accordo sulle dimensioni non appena uno dei due cambiava. Abbiamo riscritto il gestore dello schermo virtuale in modo che lo spazio di lavoro dell'host segua in tempo reale il canvas della finestra del client. Ora le dimensioni dei cursori coincidono attraverso il confine a qualsiasi dimensione della finestra, come Condivisione schermo di Apple si è sempre comportata.
punti logici dello schermo virtuale ≡ punti del canvas della finestra del client · limite in pixel 3840 · Retina 1× o 2× scelta in base all'involucro di pixel nativi della finestra
Esperimento
Perché abbiamo limitato a 3840 pixel l'involucro dello schermo virtuale.
Il framework interno di macOS che costruisce le modalità di visualizzazione degli schermi virtuali ha un comportamento silenziosamente distruttivo: quando gli viene dato un valore massimo di 4096 o più, inventa una modalità Retina 2× fantasma al massimo e si prende il flag attivo. Il numero di pixel richiesto raddoppia. Lo abbiamo confermato empiricamente in quattro notti di sondaggi e registri. 3840 va bene per ogni MacBook Retina a schermo intero più uno schermo esterno 4K, e il framework smette di sintetizzare. Stiamo ancora osservando la coda lunga.
rottura empirica a ≥ 4096 · limite = 3840 · copre MacBook Pro 16″ Retina (3456 × 2234) e schermo esterno 4K (3840 × 2160)
Rilasciato
Ritorno alla versione precedente del motore di streaming dopo un esperimento di una settimana.
Abbiamo ricostruito il nostro motore di streaming su un ramo più recente sperando che la logica di cadenza aggiornata ci facesse guadagnare qualche millisecondo sul percorso in rete locale. Invece il buffer di ricezione è peggiorato in ogni sessione remota che abbiamo misurato: la mediana end-to-end è salita di 18 ms e la variabilità si è allargata. Siamo tornati alla versione stabile su iOS, macOS, Android e Windows. Le modifiche del nuovo ramo sono archiviate nel caso in cui il comportamento a monte cambi.
latenza mediana della nuova versione · 64 ms da remoto · mediana della versione precedente · 46 ms da remoto · flag di regolazione invariati
Rilasciato
Rilevamento adattivo del bitrate tra rete locale e remoto dal primo campione del tempo di andata e ritorno.
Ora l'host attende la prima misurazione del tempo di andata e ritorno dopo l'attivazione della connessione, poi sceglie uno dei due involucri di bitrate. Sotto i 15 ms la connessione è trattata come diretta in rete locale: avvio a 8 Mbps, minimo 8 Mbps, massimo 30 Mbps. Sopra i 15 ms è trattata come con relay o distante: avvio a 2 Mbps, minimo 300 Kbps, massimo 15 Mbps. La soglia si colloca tra il Wi-Fi sulla stessa rete e qualsiasi relay cellulare o tra regioni plausibile, quindi i falsi positivi sono stati rari nella telemetria della beta.
locale diretta · 1 – 5 ms · Wi-Fi sulla stessa rete · 5 – 10 ms · relay regionale · 30 – 80 ms · 4G · 40 – 100 ms
Rilasciato
H.265 hardware su AMD come codificatore principale dell'host Windows.
Dopo un lungo confronto con codificatori concorrenti, l'H.265 hardware su AMD ha vinto tutti i benchmark dell'host Windows che ci interessavano: tempo di codifica mediano più basso, picco dei fotogrammi chiave più basso, e il preset a bitrate costante a latenza ultra bassa si comporta in modo prevedibile sotto pressione sul buffer. L'H.264 resta come ripiego quando la GPU non è d'accordo. I B-frame sono disattivati. Il flag di bassa latenza è attivo. Il codificatore emette sempre esattamente un fotogramma per ogni tick di acquisizione.
Perché abbiamo smesso del tutto di mettere i fotogrammi in buffer.
Un desktop remoto non è una videochiamata. Ogni fotogramma è lo stato più recente dello schermo. Un fotogramma vecchio è, per definizione, una bugia. Abbiamo ricostruito il percorso di ricezione in modo che non esista alcun buffer di riproduzione: un fotogramma arriva, viene decodificato, viene disegnato, in quest'ordine, nello stesso intervallo di fotogramma. Un pacchetto perso viene rinviato subito se può ancora arrivare in tempo; se non può, Remio lo salta e chiede un nuovo fotogramma invece di aspettare. Accettiamo qualche breve blocco occasionale. Non accettiamo la tassa costante di un millisecondo di una coda.
ritardo di riproduzione forzato · min 0 / max 0 · ritardo di riproduzione minimo · 0 · pacchetti persi rinviati se in tempo, altrimenti un nuovo fotogramma
Archiviato
Il budget di latenza, messo per iscritto per la prima volta.
Ci siamo seduti in una stanza e abbiamo ragionato a ritroso a partire dal numero che volevamo far sentire agli utenti: meno di venti millisecondi, da vetro a vetro, in una tipica sessione in rete locale. Acquisizione, codifica, cadenza, invio, buffer di ricezione, decodifica, rendering. Abbiamo scritto ciascuna voce e le abbiamo assegnato un budget in millisecondi che potessimo misurare. La maggior parte delle voci di questo registro nasce dal difendere quei numeri nel traffico reale.
acquisizione · 1 ms · codifica · 3 ms · raffica di cadenza · ≤ 10 ms · buffer di ricezione · 0 ms · decodifica · 2 ms · rendering · 1 ms
✦Quadro dei segnali
Cosa misuriamo, sessione dopo sessione.
Questi quattro numeri compaiono in ogni nota di rilascio perché descrivono come la connessione si sente davvero, non ciò che dichiara su una scheda tecnica.
Risoluzione dello streaming
Fino a 6Kinvolucro di pixel nativi, Retina 1× o 2× scelta per finestra
Frequenza dei fotogrammi
Fino a 120 fpscadenza fissa, B-frame disattivati, un tick di acquisizione per fotogramma
Latenza di elaborazione, rete locale
~8 msmisurata internamente su una connessione diretta da dispositivo a dispositivo: il resto è la cadenza di aggiornamento a 60 Hz del tuo schermo
Crittografia del trasporto
End-to-endcrittografia end-to-end con una nuova chiave di sessione ogni volta
Il laboratorio si aggiorna quando qualcosa arriva o qualcosa si rompe. Se ti sembra più utile di una newsletter trimestrale, il link per scaricare è a un clic di distanza, e lo stesso vale per il whitepaper sulla sicurezza, se vuoi la versione lunga.
