Remio делает небольшая команда, и делает открыто. Это рабочий журнал: пути захвата, которые мы разобрали по винтикам, настройки кодера, которые нас удивили, бюджеты задержки, которые мы превысили и выстроили заново. Новые записи — вверху; старые остаются как написаны, даже если мы с тех пор передумали.
Обновлено 2026-05-197 записейВ хронологическом порядке, новые сверху
✦Заметки исследований
Инженерный журнал по порядку.
Каждая запись датирована, имеет статус и самодостаточна. Выпущено означает, что изменение уже в последней сборке, эксперимент — что мы еще измеряем, а в архиве — что мы пошли дальше.
Выпущено
Виртуальный дисплей теперь следует за окном клиента.
Несколько недель хост macOS держал свой виртуальный дисплей на фиксированном разрешении экрана клиента, из-за чего курсор хоста и курсор клиента расходились в размере, как только менялся любой из них. Мы переписали менеджер виртуальных дисплеев так, чтобы рабочая область хоста следовала за холстом окна клиента в реальном времени. Теперь размеры курсора совпадают по обе стороны границы при любом размере окна, как всегда было в «Демонстрации экрана» Apple.
логические точки виртуального дисплея ≡ точки холста окна клиента · предел в пикселях 3840 · Retina 1× или 2× выбирается по пиксельному охвату окна
Эксперимент
Почему мы ограничили охват виртуального дисплея 3840 пикселями.
У внутренней платформы macOS, которая строит режимы дисплея для виртуальных дисплеев, есть тихое разрушительное поведение: если задать максимальный размер 4096 или больше, она придумывает фантомный режим Retina 2× на максимуме и забирает флаг активного режима. Запрашиваемое число пикселей удваивается. Мы подтвердили это опытным путем за четыре ночи проб и журналирования. Три тысячи восемьсот сорок помещаются на полный экран каждого MacBook с Retina и на внешний 4K, и платформа перестает синтезировать. Мы продолжаем следить за редкими случаями.
сбои на практике при ≥ 4096 · предел = 3840 · охватывает MacBook Pro 16″ с Retina (3456 × 2234) и внешний 4K (3840 × 2160)
Выпущено
Возврат к предыдущей сборке движка трансляции после недельного эксперимента.
Мы пересобрали движок трансляции на более новой ветке, надеясь, что обновленная логика темпа выиграет несколько миллисекунд на пути в локальной сети. Вместо этого буфер приема ухудшился в каждом измеренном удаленном сеансе: медианная сквозная задержка выросла на 18 мс, а разброс увеличился. Мы вернули стабильную сборку на iOS, macOS, Android и Windows. Патчи новой ветки заархивированы на случай, если поведение исходного проекта изменится.
Адаптивное определение битрейта для локальной сети и для удаленного подключения по первому замеру времени отклика.
Теперь хост ждет первого замера времени отклика после установки соединения, а затем выбирает один из двух диапазонов битрейта. Если меньше 15 мс, соединение считается прямым в локальной сети: старт 8 Мбит/с, минимум 8 Мбит/с, максимум 30 Мбит/с. Если больше 15 мс, оно считается ретранслируемым или удаленным: старт 2 Мбит/с, минимум 300 Кбит/с, максимум 15 Мбит/с. Порог лежит между WiFi в одной сети и любым правдоподобным сотовым или межрегиональным ретранслятором, поэтому ложные срабатывания в данных бета-тестирования были редкими.
прямое в локальной сети · 1 – 5 мс · WiFi в одной сети · 5 – 10 мс · региональный ретранслятор · 30 – 80 мс · 4G · 40 – 100 мс
Выпущено
Аппаратный H.265 на AMD как основной кодер хоста Windows.
После долгого сравнения с конкурирующими кодерами аппаратный H.265 на AMD выиграл все тесты хоста Windows, которые нас интересовали: меньшее медианное время кодирования, меньший скачок на ключевом кадре, а предустановка постоянного битрейта со сверхмалой задержкой ведет себя предсказуемо при нагрузке на буфер. H.264 остается запасным вариантом, когда GPU не согласен. B-кадры выключены. Флаг малой задержки включен. Кодер всегда выдает ровно один кадр на каждый такт захвата.
Удаленный рабочий стол — не видеозвонок. Каждый кадр — это самое новое состояние экрана. Старый кадр по определению ложь. Мы перестроили путь приема так, чтобы буфера воспроизведения не было: кадр пришел, декодировался, отрисовался — именно в таком порядке, в пределах одного интервала кадра. Потерянный пакет отправляется заново сразу, если еще может успеть; если не может, Remio пропускает его и запрашивает свежий кадр, вместо того чтобы ждать. Мы миримся с редкими короткими зависаниями. Мы не миримся с постоянной миллисекундной платой за очередь.
Мы сели в комнате и пошли от обратного — от числа, которое хотели, чтобы пользователи ощущали: меньше двадцати миллисекунд от стекла до стекла в обычном сеансе в локальной сети. Захват, кодирование, темп, отправка, буфер приема, декодирование, отрисовка. Мы записали каждый этап и дали ему бюджет в миллисекундах, с которым можно сверяться при измерениях. Большинство записей в этом журнале появилось из-за того, что мы защищали эти числа в реальном трафике.
Эти четыре числа есть в каждом описании релиза, потому что они описывают, каким соединение ощущается на самом деле, а не то, что заявлено в спецификации.
Разрешение трансляции
До 6Kродной пиксельный охват, Retina 1× или 2× выбирается для каждого окна
Частота кадров
До 120 кадров/сфиксированный ритм, B-кадры выключены, один такт захвата на кадр
Задержка обработки, локальная сеть
~8 мсизмерено внутри компании на прямом соединении между устройствами — остальное — собственный ритм обновления вашего дисплея на 60 Гц
Шифрование при передаче
Сквозноесквозное шифрование с новым ключом сеанса каждый раз
Лаборатория обновляется, когда что-то появляется или что-то ломается. Если это звучит полезнее ежеквартальной рассылки, ссылка для загрузки — в одном щелчке, как и технический документ по безопасности для тех, кому нужна полная версия.
