1. Если вы только начинаете программировать на ассемблере и не знаете с чего начать, тогда попробуйте среду разработки ASM Visual IDE
    (c) на правах рекламы
    Скрыть объявление

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

Тема в разделе "WASM.A&O", создана пользователем slow, 11 май 2006.

  1. slow

    slow New Member

    Публикаций:
    0
    Регистрация:
    27 дек 2004
    Сообщения:
    615
    Для программы типа Remote-Desktop требуется минимизировать количество трафика (т.е. к-во и размер снимков десктопа)



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



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

    asd New Member

    Публикаций:
    0
    Регистрация:
    12 мар 2005
    Сообщения:
    952
    Адрес:
    Russia
    CRC отдельных областей быть может.
     
  3. slow

    slow New Member

    Публикаций:
    0
    Регистрация:
    27 дек 2004
    Сообщения:
    615
    i.e. предлагаете разбить экран на части и попиксельно сверять?
     
  4. Same

    Same New Member

    Публикаций:
    0
    Регистрация:
    23 окт 2003
    Сообщения:
    114
    ИМХО гемороя много будет - проще будет сжимать в JPEG потом ZIPом:-) а уж потом отсылать
     
  5. HitmaN85

    HitmaN85 New Member

    Публикаций:
    0
    Регистрация:
    6 окт 2005
    Сообщения:
    36
    Можно уменьшить частоту передаваемых кадров и применить алгоритм запаковки
     
  6. Noble Ghost

    Noble Ghost New Member

    Публикаций:
    0
    Регистрация:
    28 апр 2004
    Сообщения:
    204
    Адрес:
    Russia
    OldNewThing писал что-то на эту тему, но в букмарках найти не могу =(
     
  7. slow

    slow New Member

    Публикаций:
    0
    Регистрация:
    27 дек 2004
    Сообщения:
    615
  8. SWR

    SWR New Member

    Публикаций:
    0
    Регистрация:
    11 май 2006
    Сообщения:
    226
    Адрес:
    Russia
    А непроще выщетать пикселы предыдущего кадра из нового

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

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

    slow New Member

    Публикаций:
    0
    Регистрация:
    27 дек 2004
    Сообщения:
    615
    а как интересно делает radmin?



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



    но гемороя много :dntknw:
     
  10. alpet

    alpet Александр

    Публикаций:
    0
    Регистрация:
    21 сен 2004
    Сообщения:
    1.221
    Адрес:
    Russia
    slow

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

    Folk Acid New Member

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



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

    Quantum Паладин дзена

    Публикаций:
    0
    Регистрация:
    6 янв 2003
    Сообщения:
    3.143
    Адрес:
    Ukraine
    Вычитать, ксорить... Так-то оно так, но не удобнее ли взять исходники MPEG, который как раз и сохраняет только изменения в кадрах, но через определённые промежутки времени вставляет кадр полностью на случай потери синхронизации. + ещё жмёт аки JPEG.
     
  13. AlB80

    AlB80 New Member

    Публикаций:
    0
    Регистрация:
    11 май 2006
    Сообщения:
    25
    Адрес:
    Russia
    1. MPEG сложно.

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

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

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

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

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

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

    Quantum Паладин дзена

    Публикаций:
    0
    Регистрация:
    6 янв 2003
    Сообщения:
    3.143
    Адрес:
    Ukraine
    AlB80



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

    AlB80 New Member

    Публикаций:
    0
    Регистрация:
    11 май 2006
    Сообщения:
    25
    Адрес:
    Russia
    Quantum

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



    slow

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

    Quantum Паладин дзена

    Публикаций:
    0
    Регистрация:
    6 янв 2003
    Сообщения:
    3.143
    Адрес:
    Ukraine
    AlB80



    Обоснуйте
     
  17. SWR

    SWR New Member

    Публикаций:
    0
    Регистрация:
    11 май 2006
    Сообщения:
    226
    Адрес:
    Russia
    Так после вычитание останется только изменение

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

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

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



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

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

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

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

    AlB80 New Member

    Публикаций:
    0
    Регистрация:
    11 май 2006
    Сообщения:
    25
    Адрес:
    Russia
    Quantum



    Смотри сам. :)



    SWR



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

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

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

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

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

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

    Quantum Паладин дзена

    Публикаций:
    0
    Регистрация:
    6 янв 2003
    Сообщения:
    3.143
    Адрес:
    Ukraine
    AlB80



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





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

    AlB80 New Member

    Публикаций:
    0
    Регистрация:
    11 май 2006
    Сообщения:
    25
    Адрес:
    Russia
    Quantum



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