Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 18
Где мы слабы — честно
Привет, Клод. Вы слабы в глобальной оценке, как и все ИИ на данный момент. НЕЛЬЗЯ менять аппаратный кодек на софтверный. НЕЛЬЗЯ делать кодек, без исследования существующих (а их хватает).
Да. Агенту бывает проще переписать с нуля, чем сделать WebSearch tool call.
Нет. Человеку НЕЛЬЗЯ на это соглашаться по-умолчанию.
все зелёные
...
Хабы: Open source
да? а где?
Честно не понял ничего
ну засунь тот коммент обратно в чат, он всё объяснит разжуёт
Работа проделана большая и в исследовательском плане и на практике. Снимаю шляпу.
Но в 21м веке предпочтительнее иметь дело с аппаратными ускорителями - хотя бы чтобы разгрузить CPU для чего-то полезного. От того что Rayon загрузит его по самое горло для ускорения работы кодека - пользователю продукта легче не будет. Ему ведь не просто открытый desktop нужен с быстрым обменом картинок, а что-то в нем еще и делать желательно и желательно иметь околонулевую загрузку CPU чтобы это, чем пользователь занимается (ну кроме конфлюэнса) работало так же быстро как и без remote десктопа.
Чем вас AV1 Screen Content Coding или HEVC Screen Content Coding не устроили, оба имеют аппаратную поддержку, оба могут копировать данные без изменений из предыдущего кадра?
IBC в AV1/HEVC SCC дублят графику из текущего кадра, а не из предыдущего. Копирование из прошлых кадров это обычный Inter-прогноз с квантованием. В продакшене это не работает, нет железа, нет предсказуемости.
v1/HEVC кодируют вероятностно и могут пережать статику. Наш EVRTCK дает жесткую гарантию: неизменный тайл весит ровно 1 бит.
Интересно, а какое сжатие использовал pcAnywhere, который показывал десктоп через модем 14400 на процессоре Pentium 100 с 16 мегабайтами памяти? И могут ли повторить это современные программисты - хоть с Клодом, хоть без?
Честно это крутой вопрос, попробую ответить. pcAnywher использавал RLE поверх dirty rectangles с принудительным снижением глубины цвета до 256 или 16. Никакого delta на уровне пикселя, просто арямоугольник изменился, вот он целиком, зажатый RLE. На 640х480×8 бит это работало потому что выбора не было: 14400 бод = 1440 байт/с, полный кадр = 307 КБ= 213 секунд. Значит слать можно было только то, что изменилось за один keystroke. И они слали.
Теперь математика сегодня. EVRTCK на статичном экране 20 байт на кадр. 160 бит. 14400-модем пропускает это за 11 мс. На idle-сценарии мы лучше pcAnywhere, потому что FLAG_NOP не передаёт вообще ничего осмысленного декодер просто возвращает предыдущий кадр.
Разница не в том что современные программисты разучились писать эффективный код. Разница в том что Pentium 100 обслуживал 640×480 в 256 цветах без GPU-compositing, без прозрачности, без HDR, без 4K-экранов с 60 fps. Современный рабочий стол сложнее физически: один кадр 4K BGRA — 33 МБ. pcAnywhere с тем же алгоритмом на том же железе на 4K просто не запустился бы.
На вопрос "могут ли повторить" да, могут. Вот повторили: 20 байт на статичный кадр, 408 Кбит/с при печати в терминале. На 14400-модеме это работало бы при условии что вы не двигаете окна. Ровно как в 1995.
ровно как в 1995. с одной поправкой, тогда это писали за полгода на ассемблере с осциллографом рядом. Сейчас за несколько недель на Rust с Criterion вместо осциллографа. Насчёт с Клодом или без. Не скрываю. Но 20 байт на кадр от этого не становятся 21. Инструмент меняет скорость, не физику.
Дорогой Клод, у меня возник вопрос (не умею обходить бинарное дерево) : а как же у тебя отработается scrool 50% ? Старый кадр будет переиспользован на 50% ? Просто перемещения одних кусочков данных на экране с места на место - это основа всех текущих видеокодеков.
Я не вижу у Вас с хозяином всех этих хоффманов/сдвигов. Lossless же здесь не является ответом на мой вопрос (это всё будет работать и в Lossless)
Разница в том что Pentium 100 обслуживал 640×480 в 256 цветах без GPU-compositing, без прозрачности, без HDR, без 4K-экранов с 60 fps.
Когда я подключаюсь к удаленному экрану, чтобы, скажем, видеть силу сигнала антенны, которую сейчас кручу гаечным ключом с приставной лестницы - меня вполне устроит 256 цветов без прозрачности. И 60 кадров в секунду мне не нужно, достаточно даже одного - но гарантированного, без лагов и фризов.
640х480 - это опять же камешек в огород программистов. На экране 640x480 у меня когда-то отлично помещалась панель управления Windows - даже не на полном экране, а в окошке. А теперь ту же панель управления на мониторе 4k приходится скроллить.
Если TCP-буфер переполнился и пакет потерялся
То у вас будет задержка приема(лаг), а не потеря кадра.
или все же вы про UDP, где потери пакетов возможны?
спасибо за замечание. Но тхп пакет не теряется, переполнение буфера даёт backpressure, отправитель блокируется, клиент получает лаг, но все пакеты в итоге доходят в порядке. Desync на чистом TCP возможен в другом сценарии: обрв соединения и переподключение. Новый TCP-стрим decoder сбросил прев в нули, encoder этого не знает и продолжает слать П фрейм дельты к старому prev. До следующего IDR (10 секунд) _ мусор.
Это и есть реальная проблема, которую я описал неточно. Про UDP - да, если переидем на QUIC (а это в планах), потери пакетов станут настоящей проблемой и frame hash + запрос IDR нужны уже не как теоретическая страховка, а как обязательный элемент протокола, будем копать.
Я не правильно написал про потерю пакетов применительно к TCP. Спасибо, что поправили. Что происходит на самом деле, TCP не теряет пакеты, он ритрансмитит но когда буфер переполняется, растёт RTT дальше backpressure и на стороне приложения очередь кадров начинает пухнуть. Чтобы не накапливать задержку, мы явно дропаем старые кадры из очереди на уровне приложения, в целом UDP у нас тоже есть (EVRT умеет оба транспорта), и замечу у EVRT сумасшедшая скорость, и там потери пакетов настоящие без ретрансмита. Но это отдельная тема.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
EVRTCK: тайловый дельта-кодек для удалённого рабочего стола — как мы убили H.264 для UI-контента