Remio 是由一個小團隊公開打造的。這是我們的工作紀錄——我們拆開重做的擷取路徑、讓我們意外的編碼器設定、被我們打破又重建的延遲預算。較新的條目在最上面；較舊的則保持原樣，即使我們後來改變了想法也一樣。
最後更新 2026-05-197 篇條目依時間排序，最新的在前
每個條目都標有日期與狀態，內容完整獨立。已上線表示這項變更已在最新版本中運作，實驗中表示我們仍在量測，已封存表示我們已經往前走了。
好幾週以來，macOS 主機都把虛擬顯示器固定在用戶端螢幕的解析度，這代表只要任何一邊有變動，主機游標與用戶端游標對大小的認知就會不一致。我們重寫了虛擬顯示器管理程式，讓主機的工作區即時跟隨用戶端視窗的畫布。現在不論視窗大小，跨越邊界時游標大小都會一致，就像 Apple 螢幕共享一直以來的表現。
虛擬顯示器邏輯點 ≡ 用戶端視窗畫布點 · 像素上限 3840 · Retina 1× 或 2× 依視窗原生像素範圍選擇
macOS 內部用來為虛擬顯示器建立顯示模式的框架，有個不聲不響的破壞性行為：當最大尺寸設為 4096 或以上時，它會在最大值憑空造出一個 2× Retina 的幻影模式，並搶走啟用旗標。要求的像素數量會翻倍。我們花了四個夜晚反覆探測與記錄，以實證確認了這點。3840 剛好能容納每台 Retina MacBook 的全螢幕，加上一台 4K 外接螢幕，框架也就不再憑空合成。我們仍在觀察長尾的情況。
實證在 ≥ 4096 時損壞 · 上限 = 3840 · 涵蓋 MacBook Pro 16″ Retina（3456 × 2234）與 4K 外接螢幕（3840 × 2160）
我們用較新的分支重新建置了串流引擎，希望更新後的節奏控制邏輯，能在區域網路路徑上省下幾毫秒。結果，在我們量測的每一個遠端連線上，接收緩衝區都退步了：端對端中位數增加 18 毫秒，變異也變大。我們在 iOS、macOS、Android 與 Windows 上全部退回穩定版本。新分支的修補已封存起來，以備上游的行為改變。
新版本中位數延遲 · 遠端 64 毫秒 · 先前版本中位數 · 遠端 46 毫秒 · 調校旗標未變
主機現在會在連線建立後，等待第一次往返時間的量測，然後在兩種位元率範圍中擇一。低於 15 毫秒時，連線會被視為區域網路直接連線：起始 8 Mbps、最低 8 Mbps、最高 30 Mbps。高於 15 毫秒時，則視為經由中繼或距離遙遠：起始 2 Mbps、最低 300 Kbps、最高 15 Mbps。這個門檻落在同網路 WiFi 與任何合理的行動網路或跨區域中繼之間，所以在測試版遙測中誤判很少見。
區域網路直接 · 1 – 5 毫秒 · 同網路 WiFi · 5 – 10 毫秒 · 區域中繼 · 30 – 80 毫秒 · 4G · 40 – 100 毫秒
經過與其他編碼器的長期比拚，AMD 上的硬體 H.265 在我們在意的每一項 Windows 主機基準測試中都勝出：較低的編碼時間中位數、較低的關鍵影格突波，而且超低延遲的固定位元率預設組態，在緩衝壓力下的表現可預期。當 GPU 不配合時，則以 H.264 作為備援。B 影格關閉。低延遲旗標開啟。編碼器每個擷取時刻都只輸出剛好一個影格。
位元率 · 固定 8 Mbps · fps · 60 · 緩衝 · 1 影格 · B 影格 · 0 · 預設組態 · 超低延遲
遠端桌面不是視訊通話。每個影格都是最新的螢幕狀態。舊的影格，就定義上來說，就是謊言。我們重建了接收路徑，讓它不再有播放緩衝：影格抵達、解碼、繪製，依序在同一個影格間隔內完成。遺失的封包若還來得及送達，就會立刻重新傳送；若來不及，Remio 會直接略過它，並要求一個新畫面，而不是乾等。我們接受偶爾短暫的凍結，但不接受佇列所帶來、持續不斷的毫秒稅。
強制播放延遲 · 最小 0 / 最大 0 · 最小播放延遲 · 0 · 遺失的封包若來得及就重傳，否則改要新畫面
我們坐在一個房間裡，從希望使用者感受到的數字往回推——在一般的區域網路連線中，從玻璃到玻璃不到二十毫秒。擷取、編碼、節奏控制、傳送、接收緩衝、解碼、繪製。我們把每一項都寫下來，並給它一個可以拿來量測的毫秒預算。這份紀錄裡的大多數條目，都來自於在實際流量中捍衛這些數字。
擷取 · 1 毫秒 · 編碼 · 3 毫秒 · 節奏控制突發 · ≤ 10 毫秒 · 接收緩衝 · 0 毫秒 · 解碼 · 2 毫秒 · 繪製 · 1 毫秒
這四個數字會出現在每一則版本說明中，因為它們描述的是連線實際的感覺——而不是規格表上宣稱的東西。
