Есть некий компьютер в сети, который должен передавать изображения на клиентские компьютеры изображение своего рабочего стола. (компьютеров в сети несколько десятков)
Посоветуйте, как достигнуть хорошей скорости отображения рабочего стола(расшареного) на каждом клиентском компьютере?
Сейчас, я делаю так. Копирую экран в буфер, произвожу сжатие и отправляю всем клиентам.
Предпологаю, что эфективнее отправлять не весь экран, а только часть которая изменилась с момента прошлого скриншота. Но как произвести быстрое определение изменённой области(разбить на инвалидированые прямоугольники), чтобы в итоге был выигрыш в скорости?
Или этого нужно достичь за счёт другой технологии передачи?
ЗЫ: Может кто встречал в сети подобные проекты с открытым кодом(желательно несложные), подходящие в качестве примера.
В принципе, именно этим и занимается MPEG compressor. более того, он находит вектора смещения, функции растяжения и прочие сложные преобразования изображения.
Наилучшим способом твоя задача решена в терминальном сервисе от Микрософт. На сколько я понимаю, там перехватываются GDI-вызовы и отслеживаются все изменения. Более того, текстовая информация передаётся в виде текста, а некоторые фрагменты изображения кэшируются на клиентской стороне.
Представить себе достаточно внятно, как там всё происходит на самом деле, не могу, к сожалению.
Одно "радует" — ни одна программа для удалённого управления компом не использует этой технологии. Все передают полное изображение с небольшими fps (около пяти кадров/сек) и с урезанным цветовым разрешением (не более 256 цветов, а обычно — 16)
Здравствуйте, PK Sly, Вы писали:
PS>В принципе, именно этим и занимается MPEG compressor. более того, он находит вектора смещения, функции растяжения и прочие сложные преобразования изображения.
PS>Наилучшим способом твоя задача решена в терминальном сервисе от Микрософт. На сколько я понимаю, там перехватываются GDI-вызовы и отслеживаются все изменения. Более того, текстовая информация передаётся в виде текста, а некоторые фрагменты изображения кэшируются на клиентской стороне. PS>Представить себе достаточно внятно, как там всё происходит на самом деле, не могу, к сожалению.
PS>Одно "радует" — ни одна программа для удалённого управления компом не использует этой технологии. Все передают полное изображение с небольшими fps (около пяти кадров/сек) и с урезанным цветовым разрешением (не более 256 цветов, а обычно — 16)
Да, но при этом Винда не позволяет войти в систему "неудалённому" юзеру.
А MPEG compressor, скорее всего, ориентирован на быстрое декодирование, а не кодирование. Но тут я могу ошибаться.
Здравствуйте, Offsider, Вы писали:
O>Есть некий компьютер в сети, который должен передавать изображения на клиентские компьютеры изображение своего рабочего стола. (компьютеров в сети несколько десятков) O>Посоветуйте, как достигнуть хорошей скорости отображения рабочего стола(расшареного) на каждом клиентском компьютере?
O>Сейчас, я делаю так. Копирую экран в буфер, произвожу сжатие и отправляю всем клиентам. O>Предпологаю, что эфективнее отправлять не весь экран, а только часть которая изменилась с момента прошлого скриншота. Но как произвести быстрое определение изменённой области(разбить на инвалидированые прямоугольники), чтобы в итоге был выигрыш в скорости?
O>Или этого нужно достичь за счёт другой технологии передачи?
O>ЗЫ: Может кто встречал в сети подобные проекты с открытым кодом(желательно несложные), подходящие в качестве примера.
Я бы посоветовал посмтореть материалы по H.323. Там решается подобная задача, особенно для случая нескольких пользователей... На тему упаковки — достаточно хорошо будет работать банальное попиксельное сравнение и передача только изменившихся пикселов. Если конечно ты не захочешь гнать по сети видео...
AF>Я бы посоветовал посмтореть материалы по H.323. Там решается подобная задача, особенно для случая нескольких пользователей... На тему упаковки — достаточно хорошо будет работать банальное попиксельное сравнение и передача только изменившихся пикселов. Если конечно ты не захочешь гнать по сети видео...
Можешь посоветовать что нибудь конкретнее по Н323. А то я в поисковике искал, там в основном новости на эту тему...
А попиксельное сравнение я думаю не слишком подойдёт, я ж не буду по пикселю всем клиентам рассылать обновление. Мне интересно было узнать, есть ли какие нибудь быстрые алгоритмы определения изменившихся областей(прямоугольников), что бы их перерисовывать у клиентов.
Здравствуйте, Offsider, Вы писали:
O>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Я бы посоветовал посмтореть материалы по H.323. Там решается подобная задача, особенно для случая нескольких пользователей... На тему упаковки — достаточно хорошо будет работать банальное попиксельное сравнение и передача только изменившихся пикселов. Если конечно ты не захочешь гнать по сети видео...
O>Можешь посоветовать что нибудь конкретнее по Н323. А то я в поисковике искал, там в основном новости на эту тему...
Например: здесь
O>А попиксельное сравнение я думаю не слишком подойдёт, я ж не буду по пикселю всем клиентам рассылать обновление.
Мне интересно было узнать, есть ли какие нибудь быстрые алгоритмы определения изменившихся областей(прямоугольников), что бы их перерисовывать у клиентов.
Как раз подойдёт. И весьма хорошо. Если меняется малая часть изображения (что бывает чаще) — то будет пересылаться минимум данных. Но! Попиксельное сравнение — не самая быстрая операция. Кроме того можно разбить экран на прямоугольники — допустим 8x8 или 16x16 и сравнивать попиксельно изображения. Если хотя бы один пиксел в пределах прямоугольника отличается — пересылается прямоугольник целиком. (Кстати довольно распространённый метод ). Особенно — если сранивать пикселы не последовательно в том порядке, в каком они идут в растре, а в сеточном — то скорость сравнения в среднем будет гораздо выше.
Кадры пересылаются с помощью UDP — этот протокол позволяет одновременную отправку данных нескольким получателям.
O>ЗЫ: Конечно, видео гнать не буду...
Здравствуйте, Offsider, Вы писали:
O>Есть некий компьютер в сети, который должен передавать изображения на клиентские компьютеры изображение своего рабочего стола. (компьютеров в сети несколько десятков) O>Посоветуйте, как достигнуть хорошей скорости отображения рабочего стола(расшареного) на каждом клиентском компьютере?
O>Сейчас, я делаю так. Копирую экран в буфер, произвожу сжатие и отправляю всем клиентам. O>Предпологаю, что эфективнее отправлять не весь экран, а только часть которая изменилась с момента прошлого скриншота. Но как произвести быстрое определение изменённой области(разбить на инвалидированые прямоугольники), чтобы в итоге был выигрыш в скорости?
1. GDI драйвер, кторый регистрирует все изменения или в реальном времени сообщает о них основной программе.
Дешево и сердито (пишется на коленке дня за 2-3 и работает вполне приемлимо):
2. Хранить копию экрана и с какой-то (достаточно высокой) частотой сравнивать и синхронизировать ее с реальной картинкой.
Сравнение построчное (или блоками по неаколько строк, но <32K по размеру). Все буфера вировнять на границу DWORD.
Провярять весь экран за каждый проход — необязательно, вполне приемлимые варианты четные/нечетные, 1-2-3, 1-2-3-4 + проверка соседних с измененными полос. Каждый n-ный кадр посылать весь экран целиком.
Чтение с экрана — банальный GetDIBits()
Упаковка — сначала RLE с размером слова равным глубине цвета (по эффективности сжатия почти не уступает формированию палитры вручную из наиболее используемых цветов, но работает гораздо быстрее), потом сверху какой-нибудь gzip.
При попадании в очередь Key Frame все остальние дропать.
При частоте 25 кадров в секунду с каждым 25 ключевым кадром и бинес-графике (Вижуал, офис и т.д.) на экране 1024x768x24bpp
трафик порядка полтора метра в сукунду и почти полное отсутствие артефактов из-за неполной прповерки на изменения.
O>Или этого нужно достичь за счёт другой технологии передачи?
Транспорт — UDP (желательно Multicast).
O>ЗЫ: Может кто встречал в сети подобные проекты с открытым кодом(желательно несложные), подходящие в качестве примера.
Здравствуйте, PK Sly, Вы писали:
PS>Вы его видели этот H.323 ?
Только по диагонали. Всерьез приходилось разбираться с семейством T122. PS>А зачем советуете?
Не советовал но видел.
Совет почти нормальный. —
1.Общая теория никогда не бывает лишней.
2.Если всерьез озаботиться поиском H323, обязательно придется обратить внимание на стандарты типа H261-263 и T122, которые, если заниматься задачей всерьез очень даже по теме
C>Упаковка — сначала RLE с размером слова равным глубине цвета (по эффективности сжатия почти не уступает формированию палитры вручную из наиболее используемых цветов, но работает гораздо быстрее), потом сверху какой-нибудь gzip.
Не подскажите, как преобразовать палитру в 16ти битную (например)?
И как упаковать по RLE с размером слова равным глубине цвета?
C>Транспорт — UDP (желательно Multicast).
А UDP гарантирует, что если я пошлю блок размером 100к, то не дойдёт двумя по 50к (например)?
O>А UDP гарантирует, что если я пошлю блок размером 100к, то не дойдёт двумя по 50к (например)?
да, гарантирует. но чем больше пакет, тем теньше вероятность, что он вообще дойдёт да и в виндах есть ограничение на максимальный размер сообщения в message-oriented sockets. Оно значительно меньше 100Кб.
Здравствуйте, PK Sly, Вы писали:
O>>А UDP гарантирует, что если я пошлю блок размером 100к, то не дойдёт двумя по 50к (например)?
PS>да, гарантирует. но чем больше пакет, тем теньше вероятность, что он вообще дойдёт да и в виндах есть ограничение на максимальный размер сообщения в message-oriented sockets. Оно значительно меньше 100Кб.
Блин, и что делать?
Как реализовать поставленную задачу? Может connection-oriented реализовывать?
Здравствуйте, PK Sly, Вы писали:
O>>А UDP гарантирует, что если я пошлю блок размером 100к, то не дойдёт двумя по 50к (например)?
PS>да, гарантирует. но чем больше пакет, тем теньше вероятность, что он вообще дойдёт да и в виндах есть ограничение на максимальный размер сообщения в message-oriented sockets. Оно значительно меньше 100Кб.
Попутный вопрос.
Какова разница в скорости обработки одной команды SendTo (Multicast) и несколько SendTo (To one).
Здравствуйте, PK Sly, Вы писали:
O>>Какова разница в скорости обработки одной команды SendTo (Multicast) и несколько SendTo (To one).
PS>Если работа происходит в асинхронном режиме, то без разницы (я надеюсь, речь идёт именно об этом режиме? )
Это немного облегчает задачу(если брать за основу UDP).
ЗЫ: Хотя, странно, что разницы нет...
да и в виндах есть ограничение на максимальный размер сообщения в message-oriented sockets. Оно значительно меньше 100Кб.
)
