EvertyDesk: я отдаю то, на что ушли годы

Меня зовут Артур Валиев. Я открыл исходники EvertyDesk Lite — и заодно EvertyDesk Next, то, что должно было стать следующей версией. Полностью. Без купюр.

Дальше — честный разбор того, что там внутри, без излишней скромности, но и без пафоса. Просто отчёт человека, у которого закончилось время.

Зачем вообще была эта одержимость

Удалённый доступ — штука, где кажется, что всё уже придумано: захватил экран, закодировал в H264, отправил по сети, декодировал на другом конце. RustDesk, AnyDesk, TeamViewer — всё это работает, и работает неплохо.

Но я потратил годы, разбираясь именно в кодеках — не в протоколах, не в UI, а в том, что происходит с кадром между «экран изменился» и «байты улетели в сеть». Это тот уровень, где обычно останавливаются и берут готовое: libvpx, openh264, NVENC — и живут спокойно.

Я не остановился. И вот что из этого вышло.

EVRTCK — тайловый кодек, который я не постесняюсь назвать быстрым

EVRTCK — мой собственный лосслесс тайловый кодек. Тайл 32×32, XOR-diff между кадрами, дальше ZRLE или zstd на уровне 1. Ничего революционного в идее — революционное в том, насколько плотно это утрамбовано.

Я не буду говорить излишне высокомерно. Скажу так: с транспортом EVRT1 это, скорее всего, самый быстрый вариант из того, что я видел в открытом доступе для этой задачи. 1080p-кадр — порядка 10 килобайт. Не «в среднем при хорошем сценарии», а как рабочая величина для статичного/полустатичного экрана — то есть ровно то, что происходит 90% времени в support-режиме: кто-то смотрит документ, тыкает мышкой, изредка что-то перетаскивает.

EVRTCK — лучший вариант именно для простого, обычного использования. Не для игр, не для видео на весь экран — для того, ради чего люди вообще открывают удалённый доступ: посмотреть, показать, помочь.

EVRT2 — то, чего не случилось

Честно: я писал статьи про рассинхронизацию кадров во времени, про джиттер, про то, как EVRT2 должен был решать проблему кадров, приходящих не в том порядке и не в то время. Материала на эту тему набралось на несколько статей.

В код это не попало. EVRT2 остался экспериментом — в репозитории есть его следы (evrt2_jitter, evrt2_fec, evrt2_scheduler и так далее), но в продукт он не интегрирован. Не буду делать вид, что это была стратегия. Это был проект, который не успел долететь до релиза, прежде чем у меня закончились силы.

Кому-то из тех, кто зафоркает — возможно, именно EVRT2 будет интересно дособрать.

Game-режим: EVERTY GAME + EVRT

Отдельная история — режим для игр. EVERTY GAME поверх транспорта EVRT — я писал про это отдельную статью, именно про минимальную задержку, не про качество картинки, не про битрейт, а именно про latency как главную метрику. Там, где support-режим прощает лишние 100 мс, игровой — нет.

Это не EVRTCK — для игр тайловый лосслесс не имеет смысла, там в дело идут аппаратные кодеки. Но транспорт — тот же EVRT, тот же фидбек-луп, та же логика адаптивной буферизации.

Что я на самом деле открываю

Патчи для RustDesk-совместимого транспорта

EvertyDesk не форк RustDesk, но умеет говорить на его языке — rendezvous, relay, протобаф. Я держал совместимость сознательно: это значит, что клиент можно подключить к существующей RustDesk-инфраструктуре, не поднимая ничего своего.

Заодно — совместимость по кодекам. VP8, VP9, H264, H265, AV1 — всё это есть, всё это работает по тому же протоколу, что и у RustDesk-based клиентов. То есть если вам не нужен именно EVRTCK — можете сравнивать честно, на равных, с теми кодеками, которые все знают.

Но если сравнивать между моими клиентами — самый безумно быстрый из всех именно EVRTCK. 10 килобайт на 1080p — против килобайт на порядок больше у любого видеокодека на статичной картинке.

Старый клиент — забудьте про него

Год держал EvertyDesk Lite на себе: eframe/egui, всё в одном бинарнике, вся логика хоста и вьюера в одном месте. Он рабочий. Он открыт. Но не стройте на нём планы — я сам про него забываю.

EvertyDesk Next — вот ради чего стоило дождаться

Это то, что должно было прийти на смену. Полностью нативный Rust-клиент — но вместо требовательного к кадрам egui я взял Iced. Разница ощущается сразу: не immediate-mode перерисовка всего дерева виджетов на каждый кадр, а нормальная, экономная модель обновления.

И архитектурно — разделил на лаунчер и вьювер, два отдельных процесса. Хостинг переживает крах или закрытие GUI-окна. Approval-запросы всплывают отдельным окном, независимо от того, свёрнут ли основной лаунчер. Установка как служба — Session 0 на Windows, systemd —user / launchd на Linux/macOS.

Под капотом там: NVENC, Windows Media Foundation, openh264, разные SDK — я не экономил на количестве бэкендов кодирования, потому что железо у всех разное, и на «одном универсальном кодеке» далеко не уедешь, если хочешь, чтобы это реально летало на чужих машинах, а не только на твоей.

Почему именно так, почему именно сейчас

На Хабре, если честно, немного той аудитории, которая станет разбирать построчно тайловый XOR-diff кодек. Но это не повод придержать код у себя.

Я отдаю несколько лет работы. Не потому что она закончена — она не закончена, EVRT2 тому доказательство. А потому что у меня, как у фанатика, который слишком долго варился в этом один, закончился ресурс тащить это дальше в одиночку.

Мне странно от мысли, что кто-то, прочитав это, пойдёт форкать. Странно и, чего уж там, немного жалко отдавать. Но вам, кто будет с этим работать дальше, точно виднее, что с этим делать, чем мне сейчас.

В общем — удачи, ребята. Я сдаюсь в хорошем смысле: не бросаю в мусор, а передаю. Код открыт, забирайте.

А мне пора кормить кошку. Сам бы, наверное, поголодал ещё — но времени больше нет. Пальцы V

Артур Валиев.