Remio được xây dựng bởi một đội nhỏ, một cách công khai. Đây là nhật ký công việc — những đường chụp chúng tôi mổ xẻ, những thiết lập encoder khiến chúng tôi bất ngờ, những ngân sách độ trễ chúng tôi phá vỡ rồi dựng lại. Mục mới hơn nằm trên cùng; mục cũ giữ nguyên như đã viết, kể cả khi sau này chúng tôi đã đổi ý.
Cập nhật lần cuối 2026-05-197 mụcTheo thời gian, mới nhất trước
✦Ghi chú nghiên cứu
Nhật ký kỹ thuật, theo thứ tự.
Mỗi mục có ngày, có trạng thái và độc lập. Đang triển khai nghĩa là thay đổi đã có trong build mới nhất, thử nghiệm nghĩa là chúng tôi vẫn đang đo, và lưu trữ nghĩa là chúng tôi đã đi tiếp.
Đang triển khai
Virtual display giờ đi theo cửa sổ client.
Suốt nhiều tuần, host macOS giữ virtual display cố định ở độ phân giải màn hình client, nghĩa là con trỏ host và con trỏ client bất đồng về kích thước ngay khi một trong hai thay đổi. Chúng tôi viết lại bộ quản lý virtual display để không gian làm việc của host đi theo canvas cửa sổ client theo thời gian thực. Kích thước con trỏ giờ khớp nhau qua ranh giới ở mọi kích cỡ cửa sổ, đúng cách Apple Screen Sharing vẫn luôn hoạt động.
virtual display logical points ≡ client window canvas points · giới hạn pixel 3840 · Retina 1× hoặc 2× chọn theo khung pixel native của cửa sổ
Thử nghiệm
Vì sao chúng tôi giới hạn khung virtual display ở 3840 pixel.
Framework nội bộ của macOS dùng để dựng các display mode cho virtual display có một hành vi phá hoại âm thầm: khi được cấp kích thước tối đa từ 4096 trở lên, nó bịa ra một mode Retina 2× ảo ở mức tối đa và chiếm cờ active. Số pixel yêu cầu tăng gấp đôi. Chúng tôi xác nhận điều này bằng thực nghiệm qua bốn đêm dò-và-ghi-log. Con số ba nghìn tám trăm bốn mươi vừa khít mọi MacBook Retina toàn màn hình cộng thêm một màn 4K ngoài, và framework ngừng tự sinh mode. Chúng tôi vẫn đang theo dõi phần đuôi dài.
hỏng theo thực nghiệm ở ≥ 4096 · giới hạn = 3840 · phủ MacBook Pro 16″ Retina (3456 × 2234) và màn 4K ngoài (3840 × 2160)
Đang triển khai
Quay lại build engine streaming trước sau một tuần thử nghiệm.
Chúng tôi dựng lại engine streaming trên một nhánh mới hơn với hy vọng logic pacing cập nhật sẽ mở khoá thêm vài mili-giây trên đường mạng nội bộ. Thay vào đó, receive buffer lại thoái lui trên mọi phiên từ xa mà chúng tôi đo được: độ trễ đầu-cuối trung vị tăng thêm 18 ms và độ dao động mở rộng ra. Chúng tôi quay lại build ổn định trên iOS, macOS, Android và Windows. Các bản vá của nhánh mới được lưu trữ phòng khi hành vi upstream thay đổi.
độ trễ trung vị build mới · 64 ms từ xa · độ trễ trung vị build trước · 46 ms từ xa · các cờ tinh chỉnh không đổi
Đang triển khai
Phát hiện bitrate thích ứng mạng nội bộ so với từ xa ngay từ mẫu round-trip đầu tiên.
Host giờ chờ phép đo round-trip-time đầu tiên sau khi kết nối được thiết lập, rồi chọn một trong hai khung bitrate. Dưới 15 ms, kết nối được coi là mạng nội bộ trực tiếp: khởi đầu 8 Mbps, tối thiểu 8 Mbps, tối đa 30 Mbps. Trên 15 ms, nó được coi là qua relay hoặc ở xa: khởi đầu 2 Mbps, tối thiểu 300 Kbps, tối đa 15 Mbps. Ngưỡng này nằm giữa WiFi cùng mạng và bất kỳ relay di động hay xuyên vùng nào có thể xảy ra, nên báo nhầm hiếm khi xuất hiện trong telemetry beta.
trực tiếp nội bộ · 1 – 5 ms · WiFi cùng mạng · 5 – 10 ms · relay theo vùng · 30 – 80 ms · 4G · 40 – 100 ms
Đang triển khai
H.265 phần cứng trên AMD làm encoder chính của host Windows.
Sau một cuộc so tài dài với các encoder cạnh tranh, H.265 phần cứng trên AMD thắng mọi benchmark host Windows mà chúng tôi quan tâm: thời gian encode trung vị thấp hơn, đỉnh keyframe thấp hơn, và preset constant-bitrate độ-trễ-siêu-thấp cư xử ổn định dưới áp lực buffer. H.264 vẫn là phương án dự phòng khi GPU không đồng ý. B-frame đã tắt. Cờ low-delay bật. Encoder luôn phát ra đúng một khung mỗi nhịp chụp.
Vì sao chúng tôi ngừng hẳn việc buffer khung hình.
Remote desktop không phải một cuộc gọi video. Mỗi khung hình là trạng thái màn hình mới nhất. Một khung cũ, theo định nghĩa, là một lời nói dối. Chúng tôi dựng lại đường nhận để không có playout buffer: một khung đến, nó giải mã, nó render, theo đúng thứ tự đó, trên cùng một khoảng khung. Khung bị mất sẽ yêu cầu một keyframe mới thay vì phát lại khung cũ. Chúng tôi chấp nhận thỉnh thoảng có khựng ngắn. Chúng tôi không chấp nhận khoản thuế mili-giây đều đặn của một hàng đợi.
forced playout delay · min 0 / max 0 · minimum playout delay · 0 · yêu cầu keyframe khi mất · không phát lại packet
Lưu trữ
Ngân sách độ trễ, lần đầu được ghi ra giấy.
Chúng tôi ngồi trong một căn phòng và tính ngược từ con số muốn người dùng cảm nhận — dưới hai mươi mili-giây, kính-tới-kính, trên một phiên mạng nội bộ điển hình. Chụp, encode, pace, gửi, receive buffer, giải mã, render. Chúng tôi viết từng bước ra và cấp cho nó một ngân sách mili-giây có thể đo được. Phần lớn các mục trong nhật ký này đến từ việc bảo vệ những con số đó trong lưu lượng production.
chụp · 1 ms · encode · 3 ms · pacing burst · ≤ 10 ms · receive buffer · 0 ms · giải mã · 2 ms · render · 1 ms
✦Khung tín hiệu
Điều chúng tôi đo, phiên này qua phiên khác.
Bốn con số này xuất hiện trong mọi ghi chú phát hành vì chúng mô tả kết nối thực sự cho cảm giác thế nào — không phải điều nó tuyên bố trên bảng thông số.
Độ phân giải stream
4Kkhung pixel native, 1× hoặc 2× Retina chọn theo cửa sổ
Lab cập nhật khi có gì đó ra mắt hoặc có gì đó hỏng. Nếu điều đó nghe hữu ích hơn một bản tin hàng quý, link tải về chỉ cách một cú nhấp — và whitepaper bảo mật cũng vậy, dành cho phiên bản đầy đủ.
