Маленькая, но интересная задача - уменьшение трафика в remote-desktop

Для программы типа Remote-Desktop требуется минимизировать количество трафика (т.е. к-во и размер снимков десктопа)



Решение: передавать снимки только тех частей экрана которые изменились



Вопрос: как лучше определять изменившиеся части экрана?

 

CRC отдельных областей быть может.

 

i.e. предлагаете разбить экран на части и попиксельно сверять?

 

ИМХО гемороя много будет - проще будет сжимать в JPEG потом ZIPом а уж потом отсылать

 

Можно уменьшить частоту передаваемых кадров и применить алгоритм запаковки

 

OldNewThing писал что-то на эту тему, но в букмарках найти не могу =(

 

http://blogs.msdn.com/oldnewthing/search.aspx?q=remote+desktop&p=1

здесь?



так там ничерта нет

 

А непроще выщетать пикселы предыдущего кадра из нового

Полученый результат (вычетание в байте) хорошо жмется

А на клиенте наоборот прибовлять разничу в пикселях

 

а как интересно делает radmin?



я то щас сделал глобальный хук WH_GETMESSAGE и при наступлении WM_PAINT зову GetUpdateRect



но гемороя много

 

slow

Возможно лучше перехватывать вызовы GDI, в частности BitBlt относящиеся к экранной области. Плюс к этому, оконные процедуры видимых окон, для быстрого отлова WM_PAINT/WM_PRINT.

 

А не проще ли, скажем, раз в секунду делать xor попиксельно для старой и новой матрицы точек? Потом определять сплошные ненулевые квадраты и передавать скриншоты квадратов вместе с координатами, площадь которых больше определенного размера?



Ну, или после xor'a зажимать разницу с помощью pcx

 

Вычитать, ксорить... Так-то оно так, но не удобнее ли взять исходники MPEG, который как раз и сохраняет только изменения в кадрах, но через определённые промежутки времени вставляет кадр полностью на случай потери синхронизации. + ещё жмёт аки JPEG.

 

1. MPEG сложно.

2. xor конечно интересно, но он убивает огромное кол-во инфы в изображении (т.е. ее придется передавать). Например, перетащили окошко из одного места на другое, в разнице придется передавать оба. Причем если фон был чистый, то два инвертных блока, а если картинка, то кашу одну.

3. Лучше всего доверить удалять избыточность между кадрами тому что лучше это делает.

Cмотрим zlib. Всё необходимое есть.

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

Есть предварительная тренировка словарей упаковщика и распаковщика (ну это уже совсем раритет).

Только вот алгоритмы "старые" (для труколор фото плохо пойдут) и окно сжатия маленькое (32КБ, говорят есть 64, т.е. 2 кадра не влезут), поэтому можно на стороне поискать, библиотек сжатия море.

 

AlB80

Именно поэтому я предложил исходники MPEG. Есть открытые алгоритмы сжатия видео помощнее, но они и сложнее...

 

Quantum

Рабочий стол это не видео.



slow

Лучше заглянуть на http://sourceforge.net, в проекты 7-Zip (куча готовых либ сжатия) и TightVNC (собственно само решение в исходниках).

 

AlB80

Обоснуйте

 

Так после вычитание останется только изменение

всё что не изменилось будет нулём

получений битмап хороши жмется где то на %90 и более

Это лучше MPEG Для синхронизации каждый 100 например кадр передавать полностью (или подписывать)



быстрее есле MMX для вычитания использовать

А обратно заминить вычетание на сложение

Короче использовать переполнение байта и

(можно ксорить но его трудно распаралелить(Он есть в MMX?))

 

Quantum

Смотри сам.



SWR

Бытовая ситуация сдвиг окна (курсора) и прочее.

Четко и ясно понятно, что изменение будет там где объект был и там где он стал. Причем если фоном картинка, то абзац, а не сжатие будет.

1. Надо сжимать алгоритмами устраняющими избыточность, т.е. смотри "компрессор обыкновенный".

2. Словаря компрессора должно хватать на 2 кадра целиком.

3. Желательно чтобы компрессор знал что у нас 2х мерная картинка.

4. Желательно чтобы компрессор знал формат пикселя и умел обращатся с дельтой соседних пикселей.

 

AlB80

Описываете mpeg (я уже не говорю о mpeg2, divx) и при этом настаиваете на том, что mpeg тут применять нецелесообразно...

Этот аргумент звучит неубедительно.

 

Quantum

Что хорошо мпегу с его 30 кадрами в секунду (т.е. фактически изменение отражает движение, которое и жмется), то смерть программе передающей статические картинки пару раз в секунду. Для такой программы дельта, во-1 бесполезна, во-2 вредна. Жать надо сам кадр, но имея в словаре/окне предыдущие для устранения межкадровой избыточности (поиска повторений).