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 ms，波动也变大了。我们在 iOS、macOS、Android 和 Windows 上都回退到了稳定版本。新分支的补丁已经归档，以备上游行为发生变化时使用。
新版本中位延迟 · 远程 64 ms · 先前版本中位延迟 · 远程 46 ms · 调优参数未变
主机现在会在连接建立后等待首个往返时间的测量结果，然后在两种码率范围中选择其一。低于 15 ms，连接被视为局域网直连：起始 8 Mbps，最低 8 Mbps，最高 30 Mbps。高于 15 ms，则视为经中继或距离较远：起始 2 Mbps，最低 300 Kbps，最高 15 Mbps。这个阈值介于同一网络内的 WiFi 与任何可能的蜂窝网络或跨区域中继之间，因此在测试版遥测数据中，误判很少出现。
局域网直连 · 1 – 5 ms · 同网 WiFi · 5 – 10 ms · 区域中继 · 30 – 80 ms · 4G · 40 – 100 ms
经过与多个竞争编码器的长时间比拼，AMD 上的硬件 H.265 在我们关心的每一项 Windows 主机基准测试中都胜出：编码耗时中位数更低，关键帧尖峰更低，并且超低延迟恒定码率预设在缓冲压力下表现可预测。当 GPU 不支持时，H.264 保留作为回退。B 帧关闭，低延迟标志开启。编码器每个采集周期始终只输出恰好一帧。
码率 · 恒定 8 Mbps · 帧率 · 60 · 缓冲 · 1 帧 · B 帧 · 0 · 预设 · 超低延迟
远程桌面不是视频通话。每一帧都是屏幕的最新状态，而旧的一帧，从定义上说就是一个谎言。我们重建了接收路径，使其没有播放缓冲：一帧到达，解码，渲染，依次完成，都在同一个帧间隔里。丢失的帧会请求一个新的关键帧，而不是重传旧帧。我们接受偶尔的短暂卡顿，但不接受队列带来的、持续不断的毫秒级损耗。
强制播放延迟 · 最小 0 / 最大 0 · 最小播放延迟 · 0 · 丢包时请求关键帧 · 不重传数据包
我们坐在一间屋子里，从想让用户感受到的那个数字倒推：在典型的局域网会话中，端到端低于二十毫秒。采集、编码、节奏控制、发送、接收缓冲、解码、渲染，我们把每一项都写了下来，并为它们各自定了一个可以对照测量的毫秒预算。这份日志里的大多数条目，都来自在生产流量中守住这些数字的过程。
采集 · 1 ms · 编码 · 3 ms · 节奏控制突发 · ≤ 10 ms · 接收缓冲 · 0 ms · 解码 · 2 ms · 渲染 · 1 ms
这四个数字会出现在每一次发布说明里，因为它们描述的是连接实际用起来的感觉，而不是规格表上宣称的内容。
