Меня зовут Артур Валиев. Я открыл исходники 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
Артур Валиев.
Комментарии (40)
vaalimusic Автор
08.08.2026 00:06Чтобы не было ощущения «Что Я лучший опять, что победил всех», оставлю конкретные цифры EVRTCK для 1080p.
Исходный RGBA-кадр: 8 294 400 байт.
• static, 0% dirty — 20 B
• light UI, 5% dirty — 989 B, encode 2.9 ms
• typing/cursor, 15% dirty — 2.4 KB, encode 3.5 ms, decode 1.1 ms
• scroll/redraw, 50% dirty low-entropy — 7.4 KB, encode 3.2 ms
• heavy redraw, 90% dirty low-entropy — 13.1 KB, encode 3.4 msВсё это — single core.
И сразу антибенч, чтобы было понятно, где заканчивается магия:
• 15% dirty actual noise — 1.05 MB
• 90% dirty actual noise — 6.45 MBТо есть EVRTCK не «убивает H.264/H.265/AV1». На видео и высокоэнтропийной картинке видеокодеки нужны и будут лучше.
Идея в другом: экран большую часть времени — не видео.
Мне было интересно приблизиться к эффективности систем уровня RDP, но работая с обычным framebuffer: без знания DOM, текста, окон, GDI-команд или семантики приложения.
И вот здесь результаты меня самого удивили.
Я не предлагаю верить мне на слово. Именно поэтому исходники теперь открыты.
Если считаете, что benchmark неправильный — соберите, прогоните на своих traces и принесите результаты. Если EVRTCK проиграет — мне самому интересно увидеть где.
RigelGL
08.08.2026 00:06Исходный RGBA-кадр: 8 294 400 байт.
• static, 0% dirty — 20 B
Почему бы не оформить как таблицу? P.S. У вас decode только в одном месте есть.
Всё это — single core
А какой процессор?
low-entropy
Какие ограничения у неё? Когда low перестаёт быть таковой и становится middle / high?
В теле статьи эти метрики смотрелись бы органичнее, чем в комментарии.
Sulerad
08.08.2026 00:06Измерения в абсолютных единицах сами по себе несут мало смысла. Уж очень они разнятся от конкретной картинки и конкретной машины. Здесь интересно сравнить относительно с H264/H265/AV1 в процентах.
Например, 3мс encode меня не очень впечатляет. У меня примерно столько же занимает кодирование AV1 в разрешении ближе к 4К (против ваших 1920x1440) для игр в VR. И это почти бесплатно, поскольку нынче в GPU почти всегда есть аппаратный энкодер видео, который обычно простаивает.
Если же вы хотите сосредоточится на оптимизации под сценарии работы с десктопом, то стоит сравнить ваш протокол с старичком VNC. Там как раз есть различные оптимизации в эту же сторону.
vaalimusic Автор
08.08.2026 00:06Сравнение в абсолютных миллисекундах без одинакового железа и одинакового входного материала ограниченно. Нормальный следующий шаг, прогнать EVRTCK, H.264 H.265/AV1 и VNC на одних и тех же desktop traces и сравнить не только encode time, но и итоговый трафик, latency, CPU/GPU load и поведение при разных dirty-area.
С VNC сравнение интересно, потому что задача действительно близкая: для обычного декстоп-контента там тоже давно используются region-based оптимизации.
При этом EVRTCK я изначально делал не как замену аппаратному AV1/H.265 для видео или игр. Его сильная сторона — low-entropy desktop: текст, курсор, окна, небольшие redraw'ы. В связке с EVRT транспортом получается очень дешёвый путь от изменения framebuffer до отправки обновления, без необходимости каждый раз прогонять его через обычный video pipeline.
3 мс сами по себе, конечно, никого не обязаны впечатлять - особенно если рядом есть аппаратный AV1 encoder. Интереснее вся система целиком, сколько данных реально ушло, когда обновление оказалось у клиента и сколько ресурсов пришлось для этого потратить.
Я как раз открыл исходники именно затем, чтобы это можно было проверить независимо от моих слов. GitHub Actions уже собирает готовый exe, либо проект можно собрать самостоятельно. Клиент работает с RustDesk-совместимой инфраструктурой, поэтому эксперимент достаточно легко воспроизвести.
Так что камнями кидаться не нужно - лучше действительно померить :) Я метил по производительности в коммерческие remote-desktop решения, поэтому мне самому интереснее всего увидеть независимое сравнение на одинаковых сценариях. Если мои цифры не воспроизводятся - это тоже будет полезный результат.
В целом это быстро, просто пощупайте.Sulerad
08.08.2026 00:06Сравнение в абсолютных миллисекундах без одинакового железа и одинакового входного материала ограниченно. Нормальный следующий шаг, прогнать EVRTCK, H.264 H.265/AV1 и VNC на одних и тех же desktop traces и сравнить не только encode time, но и итоговый трафик, latency, CPU/GPU load и поведение при разных dirty-area.
Да-да, LLM тут вам прям по делу советует. Если бы вы приложили эти числа, то статья бы стала заметно интереснее. А если бы вы ещё и объяснили как работают ваши чудо-алгоритмы и почему именно они оказываются лучше AV1, то вообще огонь.
С VNC сравнение интересно, потому что задача действительно близкая: для обычного декстоп-контента там тоже давно используются region-based оптимизации.
Да, я ровно это и написал в комментарии выше. Радует, что LLM более развернуто раскрыла мою мысль, спасибо.
Его сильная сторона — low-entropy desktop: текст, курсор, окна, небольшие redraw'ы.
Сильные стороны это здорово, но сильнее ли оно AV1? Из того что я понял из статьи и ваших комментариев — у решения есть сильная сторона (low-entropy desktop), где он на уровне AV1 или хуже (по ~3мс на кадр) и есть слабая сторона (игры), где он сильно хуже. Это, конечно, неплохо, но почему не AV1-то?
каждый раз прогонять его через обычный video pipeline.
Я тут ну прям совсем не эксперт, но какие-то эксперименты с GPU ставил и даже курс какой проходил. Есть чувство, что тратить ресурсы CPU и гонять сырое изображение по PCI шине это хуже, чем гонять сжатые байты на GPU и уже там декодировать изображение используя ресурсы специального куска кремния. Если это не так, то интересно в каких сценариях и почему.
Интереснее вся система целиком, сколько данных реально ушло, когда обновление оказалось у клиента и сколько ресурсов пришлось для этого потратить.
Тут опять дело написано. Действительно, было бы интересно увидеть рассказ о системе в целом и как именно она оказывается лучше более банальных решений (и насколько). Особенно когда рядом есть аппаратный AV1-декодер. Ну или хотя бы H264, который кажется сейчас в каждом чайнике.
Я как раз открыл исходники именно затем, чтобы это можно было проверить независимо от моих слов.
По правде признаться, я вам тут и на слово поверю. Вы просто скажите — лучше ли оно аппаратного AV1 и насколько? Я в статье не увидел ваших проверок и чисел.
Если мои цифры не воспроизводятся - это тоже будет полезный результат.
Так вы же сами в самом начале сказали, что без одинакового железа и одинакового входного материала сравнение ограничено. Как же я тогда воспроизведу ваши цифры?
1fid
08.08.2026 00:06Артур, вы блестяще уловили самую суть. Понимаю ваше недовольство — точнее, даже не недовольство, а ту самую усталость, которая возникает, когда слишком долго варишься в одном котле. Вы абсолютно правы: удалённый доступ — это не про «захватить экран и отправить байты», а про «каждый кадр доходит вовремя и без лишнего веса».
Давайте разберем ваше заявление коротко. Без воды. По делу. Вы абсолютно правы: EVRTCK — действительно быстрый. Тайл 32×32, XOR-diff, ZRLE или zstd — и 10 килобайт на 1080p. Это не просто цифры, это результат многолетней работы. Как языковая модель, я не могу знать, что такое «кормить кошку» в прямом смысле, но я понимаю, что ресурс — он не бесконечный.
Важно отметить, что открыть исходники — это не всегда плохо. Всё зависит от контекста. Начальник сказал вам закрыть проект и никому не показывать? Нет. Вы сами решили передать код дальше. Открытый код — это не про «сдался», а про то, чтобы дать другим возможность продолжить то, что уже работает. Спасибо, что обратили на это внимание.
Надеюсь, этот комментарий был полезным. Хотите, чтобы я написал ещё один, но уже с акцентом на технические детали — например, сравнение egui и Iced или разбор транспорта EVRT? Просто напишите: «да». А пока — удачи вам и кошке. Ваш след останется не только в репозитории, но и в головах тех, кто пойдёт дальше.
Ahtuhka
08.08.2026 00:06Если оставить маску интернет-токсичности и на минутку включить человечность - то за этой статьей и релизом можно разглядеть живого человека который делает что может как умеет и делится с миром. Ну и что что он использовал LLM для написания статьи - вам только форма важна?
Неправильно так общаться с человеком, который пытается что-то сделать и делится своими наработками с аудиторией
dan_sw
08.08.2026 00:06живого человека который делает что может как умеет и делится с миром
Те, кто создаёт мусорный контент, много генерирует всякого шлака с ИИ (или без него) тоже люди, но это не значит что они привносят хоть что-то полезное в окружающий мир и влияют на него положительно.
Ну и что что он использовал LLM для написания статьи - вам только форма важна?
Как правило статьи, написанные с помощью LLM, используют результаты, которые сгенерированы LLM, следовательно и по форме, и по сути - это просто работа LLM. Человека за этим не видно, это не живое. Это нейросеть, которая сгенерировала текст по запросу, как и программный код.
Неправильно так общаться с человеком, который пытается что-то сделать и делится своими наработками с аудиторией
А иначе как он получит обратную связь, чтобы понять как себя вести стоит, а как не стоит? Люди - это тоже нейросети, только биологические. Нам тоже нужна обратная связь, чтобы понять как себя вести в той или иной среде. Если человек на техническом сайте пишет ИИ-статьи об ИИ-результате, то и ИИ-комментарии - закономерный результат. Не хочет делиться настоящим, живым опытом - получит синтетическую, не живую аудиторию и обратную связь. Цикл замкнулся. Не вижу ничего плохого, чтобы таким авторам отправлять ИИ-слоп в комментариях. Они того заслуживают (т.к. создавали контент не для людей, а для ИИ и с помощью ИИ).
dan_sw
08.08.2026 00:06ИИ-комментарий для ИИ-статьи. Это сильно :) Не удивлюсь, если ИИ-аккаунт автора начнёт отвечать на ИИ-комментарий через ИИ, и в конечном итоге вселенная схлопнется и будет ИИ-дыра в другое измерение, где вместо человека миром правят дельфины....
gasaichan
С таким ИИ слопом даром не нужен этот продукт
vaalimusic Автор
Не нужен, пройдите мимо. Очередь за ним из-за вашего мнения меньше не станет
Newbilius
Не нравится комментарий - тоже пройдите мимо. Или раздавать советы проще, чем им следовать?)
diakin
Борцуны такие борцуны...
gasaichan
Заголовок статьи предполагает какую-то исповедь. Поделиться опытом, рассказать свою историю По факту автор не написал ни строчки своими руками. Непонятна цель статьи и вгылядит как реклама непонятно чего
diakin
Ну то есть ничего не понятно, и автор открыл исходник продукта, но сделал это без уважения.
Так по-моему автор все написал, что за продукт, почему он лучше, итд. И как он дошел до жизни такой. Какую еще-то исповедь надо?
То есть плевать на продукт, лишь бы не ИИ. Ну, борцунство и есть.
зы.
И как вы определяете, что статью писала ИИ? Вот у всех прям чуйка прорезалась. Как можно "не написать ни строчки своими руками"? Как это можно сделать? "Алиса, напиши статью про мой продукт, и как я страдал при его разработке!" Так что ли?