Remio dibuat oleh tim kecil secara terbuka. Ini log kerjanya — jalur capture yang kami bongkar, pengaturan encoder yang mengejutkan kami, anggaran latensi yang kami jebol lalu bangun ulang. Entri terbaru ada di atas; yang lama tetap seperti saat ditulis, bahkan ketika kami kemudian berubah pikiran.
Terakhir diperbarui 2026-05-197 entriKronologis, terbaru di atas
✦Catatan riset
Log rekayasa, berurutan.
Setiap entri bertanggal, berstatus, dan berdiri sendiri. Dirilis berarti perubahannya sudah aktif di build terbaru, eksperimen berarti kami masih mengukur, dan diarsipkan berarti kami sudah beralih.
Dirilis
Layar virtual kini mengikuti jendela klien.
Selama berminggu-minggu, host macOS menjaga layar virtualnya tetap pada resolusi layar klien, yang berarti kursor host dan kursor klien berbeda ukuran begitu salah satunya berubah. Kami menulis ulang pengelola layar virtual agar ruang kerja host mengikuti kanvas jendela klien secara real time. Kini ukuran kursor sama di kedua sisi batas pada ukuran jendela apa pun, seperti perilaku Apple Screen Sharing selama ini.
poin logis layar virtual ≡ poin kanvas jendela klien · batas piksel 3840 · Retina 1× atau 2× dipilih sesuai cakupan piksel asli jendela
Eksperimen
Mengapa kami membatasi cakupan layar virtual pada 3840 piksel.
Framework internal macOS yang membuat mode layar untuk layar virtual memiliki perilaku merusak yang tidak kentara: saat diberi dimensi maksimum 4096 atau lebih, framework ini mengarang mode Retina 2× fiktif pada ukuran maksimum dan merebut penanda aktif. Jumlah piksel yang diminta menjadi dua kali lipat. Kami memastikannya secara empiris lewat probe dan log selama empat malam. Angka 3840 muat untuk setiap layar penuh MacBook Retina ditambah monitor eksternal 4K, dan framework berhenti mengarang mode. Kami masih memantau kasus-kasus langka.
kerusakan empiris pada ≥ 4096 · batas = 3840 · mencakup MacBook Pro 16″ Retina (3456 × 2234) dan monitor eksternal 4K (3840 × 2160)
Dirilis
Kembali ke build mesin streaming sebelumnya setelah eksperimen satu minggu.
Kami membangun ulang mesin streaming kami di atas cabang yang lebih baru dengan harapan logika pacing yang diperbarui bisa menghemat beberapa milidetik pada jalur jaringan lokal. Namun buffer penerima justru memburuk di setiap sesi jarak jauh yang kami ukur: median ujung ke ujung naik 18 ms dan variansnya melebar. Kami kembali ke build stabil di iOS, macOS, Android, dan Windows. Patch cabang baru diarsipkan seandainya perilaku upstream berubah.
median latensi build baru · 64 ms jarak jauh · median build sebelumnya · 46 ms jarak jauh · flag penyetelan tidak berubah
Dirilis
Deteksi bitrate jaringan lokal versus jarak jauh yang adaptif dari sampel round-trip pertama.
Kini host menunggu pengukuran round-trip time pertama setelah koneksi terbentuk, lalu memilih salah satu dari dua cakupan bitrate. Di bawah 15 ms, koneksi dianggap langsung di jaringan lokal: mulai 8 Mbps, minimum 8 Mbps, maksimum 30 Mbps. Di atas 15 ms, koneksi dianggap melalui relay atau berjarak jauh: mulai 2 Mbps, minimum 300 Kbps, maksimum 15 Mbps. Ambang batas ini berada di antara WiFi di jaringan yang sama dan relay seluler atau lintas wilayah mana pun, sehingga salah deteksi jarang terjadi di telemetri beta.
langsung lokal · 1 – 5 ms · WiFi jaringan sama · 5 – 10 ms · relay regional · 30 – 80 ms · 4G · 40 – 100 ms
Dirilis
H.265 perangkat keras di AMD sebagai encoder utama host Windows.
Setelah adu uji yang panjang melawan encoder lain, H.265 perangkat keras di AMD menang di setiap benchmark host Windows yang kami pedulikan: waktu encode median lebih rendah, lonjakan keyframe lebih rendah, dan preset ultra-low-latency dengan bitrate konstan berperilaku dapat diprediksi saat buffer tertekan. H.264 tetap menjadi cadangan saat GPU tidak cocok. B-frame dimatikan. Flag low-delay dinyalakan. Encoder selalu mengeluarkan tepat satu frame per tick capture.
Mengapa kami sama sekali berhenti mem-buffer frame.
Remote desktop bukan panggilan video. Setiap frame adalah keadaan layar terbaru. Frame lama, menurut definisinya, adalah kebohongan. Kami membangun ulang jalur penerimaan tanpa buffer pemutaran: frame tiba, di-decode, dirender, berurutan, dalam interval frame yang sama. Paket yang hilang dikirim ulang segera jika masih bisa tiba tepat waktu; jika tidak, Remio melewatinya dan meminta frame baru alih-alih menunggu. Kami menerima sesekali pembekuan singkat. Kami tidak menerima pajak milidetik tetap dari sebuah antrean.
forced playout delay · min 0 / maks 0 · minimum playout delay · 0 · paket hilang dikirim ulang jika masih tepat waktu, jika tidak frame baru
Diarsipkan
Anggaran latensi, ditulis untuk pertama kalinya.
Kami duduk di satu ruangan dan bekerja mundur dari angka yang ingin dirasakan pengguna — di bawah dua puluh milidetik, dari kaca ke kaca, pada sesi jaringan lokal yang umum. Capture, encode, pace, kirim, buffer penerima, decode, render. Kami menuliskan masing-masing dan memberinya anggaran milidetik yang bisa kami ukur. Sebagian besar entri di log ini berasal dari upaya mempertahankan angka-angka itu pada lalu lintas produksi.
capture · 1 ms · encode · 3 ms · pacing burst · ≤ 10 ms · buffer penerima · 0 ms · decode · 2 ms · render · 1 ms
✦Cakupan sinyal
Yang kami ukur, sesi demi sesi.
Keempat angka ini ada di setiap catatan rilis karena menggambarkan bagaimana koneksi benar-benar terasa — bukan apa yang diklaim di lembar spesifikasi.
Resolusi stream
Hingga 6Kcakupan piksel asli, Retina 1× atau 2× dipilih per jendela
Frame rate
Hingga 120 fpsirama tetap, B-frame dinonaktifkan, satu tick capture per frame
Latensi pemrosesan, jaringan lokal
~8 msdiukur secara internal pada koneksi langsung perangkat ke perangkat — sisanya adalah irama refresh 60 Hz layar Anda sendiri
Enkripsi transport
Ujung ke ujungenkripsi ujung ke ujung dengan kunci sesi baru setiap kali
Lab diperbarui saat ada yang selesai atau ada yang rusak. Kalau itu terdengar lebih berguna daripada buletin kuartalan, tautan unduhnya hanya sekali klik — begitu juga whitepaper keamanan untuk versi lengkapnya.
