The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Просмотрщик VNC, отображающий активность на рабочем столе в виде анимированных GIF-изображений

27.05.2013 09:13

Андрей Сидоров представил проект vnc-over-gif, в рамках которого подготовлен работающий в браузере VNC-просмотрщик, использующий для отображения содержимого удалённого рабочего стола поток в виде анимированного GIF-изображения. Данные передаются в форме непрерывного потока, а не отдельных файлов, что потребовало внесение изменения в библиотеку для формирования анимированных GIF.

Код серверной части, транслирующей вывод от VNC-сервера, написан на JavaScript и работает под управлением Node.js. На стороне клиента для просмотра сеанса рабочего стола достаточно поддержки анимированных GIF-изображений (следует открыть ссылку вида http://localhost:4455/screen.gif?host=хост&port=5900&password=пароль), т.е. поддерживаются браузеры начиная с выпущенного в 1995 году Netscape Navigator 2.0.

  1. Главная ссылка к новости (http://www.theregister.co.uk/2...)
Лицензия: CC-BY
Тип: Программы
Ключевые слова: vnc, gif
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (47) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Омский линуксоид (ok), 10:24, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Тяжеловато наверное... Переписывать на С будут?
     
     
  • 2.10, pavlinux (ok), 14:02, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Бойян - у нас такое работает аж с 2006 году. Не GPL и не опен соурс. ФСБ Private License :)

    Кстати в двух вариантах: один GIF или pJPEG с задаваемой в реалтайме частотой.
    Ессесенно шифрование по 89 или 2004 ГОСТам, можно SSL/DES/AES врубить.  
    Более того, VNC это всего лишь один из вариантов транспорта, дамп экрана
    снимается прям в ядре с устройства. Можно пихать эти дампы сплющенные LZMA,
    прям в езернет/ip/http фреймы. А еще есть вариант JPEG-diff - отсылаются
    только изменения от предыдущего фрейма, обратная сборка перекладывается на клиента.

     
     
  • 3.11, Аноним (-), 14:25, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да ты крутой!
     
     
  • 4.12, pavlinux (ok), 14:30, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Да ты крутой!

    Потому, что Гладиолус!

     
  • 3.18, Аноним (-), 17:05, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Бойян - у нас такое работает аж с 2006 году. Не GPL
    > и не опен соурс. ФСБ Private License :)
    > Кстати в двух вариантах: один GIF или pJPEG с задаваемой в реалтайме
    > частотой.
    > Ессесенно шифрование по 89 или 2004 ГОСТам, можно SSL/DES/AES врубить.
    > Более того, VNC это всего лишь один из вариантов транспорта, дамп экрана
    > снимается прям в ядре с устройства. Можно пихать эти дампы сплющенные LZMA,
    > прям в езернет/ip/http фреймы. А еще есть вариант JPEG-diff - отсылаются
    > только изменения от предыдущего фрейма, обратная сборка перекладывается на клиента.

    А что ж вы не пользуетесь легендарной сетевой прозрачностью иксов, про которую нам прожужжали все уши?

     
     
  • 4.34, Vkni (ok), 06:55, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > А что ж вы не пользуетесь легендарной сетевой прозрачностью иксов, про которую
    > нам прожужжали все уши?

    Винды ж, небось.

     
  • 3.23, Аноним (-), 19:04, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > снимается прям в ядре с устройства. Можно пихать эти дампы сплющенные LZMA,

    Можно. Только LZMA тормозной при сжатии и проц озадачится конкретно.

     
     
  • 4.31, all_glory_to_the_hypnotoad (ok), 22:05, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    т.е. нельзя,  на практике. И не даст оно сильно большого прироста сжатия на таких объёмах
     
     
  • 5.40, Аноним (-), 07:26, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > т.е. нельзя,  на практике.

    Ну я саркастично намекнул павлину что ему не понравится нагрузка на проц :). Если ему делать нех - пусть zpaq жмет. Сжатие будет одно из лучших в мире. А то что там скорость сжатия полметра в час - да подумаешь, эка невидаль...

     
  • 3.26, Аноним (-), 20:33, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Бойян - у нас такое работает аж с 2006 году. Не GPL и не опен соурс. ФСБ Private License :)

    Под Win, что ли. Такие только ей давали. Не может это работать.

    Проговорился.

     
  • 3.33, all_glory_to_the_hypnotoad (ok), 22:09, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ну это не удивительно, все гос. учреждения просто кладезь идиотизма.
     
  • 3.45, slay (??), 23:35, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    итак езернет-фреймы, ip, или http? че вы теплое с мягким перепутали в стремлении показать как оно там у вас огого..
     

  • 1.2, Аноним (2), 10:55, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Крутая штука! Жалко только, что только посмотрщик. Но это дело времени. Так держать!!)))
     
     
  • 2.3, Гость (?), 11:36, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Изображение можно сделать фоновым и регистрировать клики и перемещение курсора на стороне пользователя.
     
     
  • 3.4, Andrey Mitrofanov (?), 11:43, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Изображение можно сделать фоновым и регистрировать клики и перемещение курсора на стороне пользователя.

    Ждём новостей!

    * На основе бblдло-хаб-лицензированного node.js просмотрщика выпущен полнофункцианальный конкурент teamviewer-а
    * Зарегистрированы первые взломы клиетов нового полнофункционального...
    * Обнаружен троян, имитирующий тимвьюер, на основе полнофункционального...
    * Новые еженедельные уязвимости: ..., диирки в коде обработки gif полнофункционального...

     
     
  • 4.5, Andrey Mitrofanov (?), 11:46, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > * На основе бblдло-хаб-лицензированного node.js просмотрщика

    Поправочка: бblдло-MIT-лицензированного

    vnc-over-gif / package.json

    2 contributors
    file 31 lines (30 sloc) 0.597 kb
    1 {
    2  "name": "vnc-over-gif",
    3   "version": "0.0.2",
    4   "description": "vnc over gif server",
    [...]
    24 "license": "MIT",

     
  • 4.6, Сергей (??), 11:54, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты-то сам хоть что-нибудь написал?
     
     
  • 5.7, Andrey Mitrofanov (?), 12:02, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ты-то сам хоть что-нибудь написал?

    Много постов на опеннет.

    ---24 "license": "Alright reserved",

     
     
  • 6.35, бедный буратино (ok), 07:15, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ты-то сам хоть что-нибудь написал?
    > Много постов на опеннет.
    > ---24 "license": "Alright reserved",

    Однажды Мастер Фу сказал заезжему программисту: "В одной строке кода shell-сценария больше духа Unix, чем в десяти тысячах строк на языке С!"

    Программист, гордый своими познаниями в С, ответил: "Может ли быть такое? Ведь С — язык, в котором реализовано само ядро Unix!"

    На это Мастер Фу ответил: "Это так. Тем не менее, в одной строке shell-сценария больше духа Unix, чем в десяти тысячах строк С!"

    Программист выглядел удрученным. "Но ведь через язык С мы познаем просвещенность патриарха Ритчи! Мы уподобляемся человеку с операционной системой и компьютером, который получает непревзойденную производительность!"

    Мастер Фу сказал: "То, что ты говоришь, правда. Однако в одной строке shell-сценария больше духа Unix, чем в десяти тысячах строк С".

     
     
  • 7.41, Аноним (-), 07:29, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Это был не мастер Фу. Это, вероятно, был FUBAR.
     
     
  • 8.43, Andrey Mitrofanov (?), 09:56, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На Форумк Опеннет обнаружен Аноним-самозванец, не чтящий классику ... текст свёрнут, показать
     
  • 3.14, Клыкастый (ok), 15:39, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    смотри-ка... походу привинтить к костылям костыли много желающих.
     
     
  • 4.17, Аноним (-), 17:04, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ЭВМ - это костыли для тех, кто не осилил счеты. Очевидно, что среди пользователей ЭВМ одни любители костылей.
     
     
  • 5.19, Клыкастый (ok), 17:32, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > ЭВМ - это костыли для тех, кто не осилил счеты. Очевидно, что
    > среди пользователей ЭВМ одни любители костылей.

    Ты не считаешь костылями гонять по сети битмапы?

     
     
  • 6.22, Аноним (-), 18:55, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ты не считаешь костылями гонять по сети битмапы?

    В конечном итоге, картинка с десктопе - это неизбежно битмап :). Просто передавать его можно по разному. Можно и крайне субоптимально. Вот gif с его 256 цветов и неважной степенью сжатия - знатный костыль.

     

  • 1.8, vitalif (?), 12:55, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Между прочим, в прошивках дешёвеньких IP-камер D-Link есть фича - они умеют отдавать то ли "MJPEG", то ли "MPNG" с помощью бесконечной отдельных кадров по Server-Push :) т.е. работает в Firefox. А в Chrome кстати есть серверпуш?
     
     
  • 2.9, Аноним (-), 13:40, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    у меня zoneminder так с одной китайской камеры поток снимает :)
     
  • 2.21, Аноним (-), 18:53, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > отдавать то ли "MJPEG", то ли "MPNG" с помощью бесконечной отдельных кадров

    Это mjpeg. Он есть. Но он отличается хреновой эффективностью соотношением траффика к качеству картинки. Потому что даже дельта-компрессии между кадрами - нет, каждый кадр передается целиком. Соотношение битрейт/качество при этом ни к черту.

     
     
  • 3.24, Аноним (-), 19:18, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> отдавать то ли "MJPEG", то ли "MPNG" с помощью бесконечной отдельных кадров
    > Это mjpeg. Он есть. Но он отличается хреновой эффективностью соотношением траффика к
    > качеству картинки. Потому что даже дельта-компрессии между кадрами - нет, каждый
    > кадр передается целиком. Соотношение битрейт/качество при этом ни к черту.

    Для систем наблюдения - MJPEG гораздо лучше, чем "более эффективные" кодеки. Банально потому что каждый кадр никак не зависит от качества обработки предыдущих, не теряются мелкие детали.

     
     
  • 4.29, Аноним (-), 20:35, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>> отдавать то ли "MJPEG", то ли "MPNG" с помощью бесконечной отдельных кадров
    >> Это mjpeg. Он есть. Но он отличается хреновой эффективностью соотношением траффика к
    >> качеству картинки. Потому что даже дельта-компрессии между кадрами - нет, каждый
    >> кадр передается целиком. Соотношение битрейт/качество при этом ни к черту.
    > Для систем наблюдения - MJPEG гораздо лучше, чем "более эффективные" кодеки. Банально
    > потому что каждый кадр никак не зависит от качества обработки предыдущих,
    > не теряются мелкие детали.

    Всего ничего - звука только нету.

     
     
  • 5.37, Аноним (-), 07:20, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Всего ничего - звука только нету.

    И соотношение битрейт/качество ни к черту. Так что или видеонаблюдать 320x240x5FPS, или качество сжатия ставить "ой, а что это за квадратики?", или оно канал забьет. Видеопотоком это недоразумение можно считать весьма условно.

     
  • 4.36, Аноним (-), 07:19, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > не теряются мелкие детали.

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

    Поэтому получить качественную картинку высокого разрешения с отображением деталей и без искажений - это вообще совсем не про mjpeg. Он обычно может показывать слайд-шоу умеренного разрешения с средненьким качеством. На что-то сверх того ему не хватит бандвиза. Как раз потому что каждый кадр шлется целиком. Даже если вообще не отличается от прошлого кадра ни на бит.

     

  • 1.15, Аноним (-), 15:49, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Г-нецо. Никакой поддержки flow control, изменения частоты обновлений в зависимости от ширинцы канала и пропуска кадров там нет - если канал узкий, будете видеть состояние экрана часовой давности. Не нужно.
     
  • 1.16, EuPhobos (ok), 16:24, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    http://... ... ...&password=
    "Может ещё и ключи от квартиры"

    Пароль по http только если в тунели ssh.

     
  • 1.20, Аноним (-), 18:52, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > поток в виде анимированного GIF-изображения

    Про более эффективное сжатие, например webm - этот чудак не слышал? Поточное видео из гифок - это жосска.

     
     
  • 2.30, Аноним (-), 20:37, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> поток в виде анимированного GIF-изображения
    > Про более эффективное сжатие, например webm - этот чудак не слышал? Поточное
    > видео из гифок - это жосска.

    И чо что GIF? Зато патентами не обложен (кончились они). Бери и юзай.

     
     
  • 3.38, Аноним (-), 07:22, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И чо что GIF? Зато патентами не обложен (кончились они). Бери и юзай.

    Спасибо, сами такое юзайте как-нибудь. Меня 256-цветная графика сервируемая методом "гланды, через ж...у, автогеном" как-то совершенно не возбуждает.

     
     
  • 4.44, Аноним (-), 13:38, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Непонятно, что Вы вкладываете в смысл 256-цветной графики. Представляется, что Вы не знаете, что 256 цветов могут быть в определенной палитре, например, в серой, превращаясь в оттенки (в данном случае это более точное определение). Т.о., 256 цветов (оттенков) может быть не так мало для некоторых задач. Например, для охранного наблюдения или наблюдения за действиями пользователей этого достаточно. И с точки зрения производительности гонять по сети 24-битные картинки просто глупо.
     
     
  • 5.47, Аноним (-), 05:20, 29/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Непонятно, что Вы вкладываете в смысл 256-цветной графики.

    То самое, не более 256 цветов в единицу времени. Что намекает что полноцветной графики там в принципе не видать.

    > Представляется, что Вы не знаете, что 256 цветов могут быть в определенной палитре,

    Знаю, но в палитре только 256 записей. Адаптивная палитра конечно сделает картинку лучше, но до 24 битов этому как пехом до Пeкина.

    > Т.о., 256 цветов (оттенков) может быть не так мало для некоторых задач.

    Для некоторых, ага.

    > Например, для охранного наблюдения или наблюдения за действиями пользователей этого достаточно.

    Это вообще не применение а идиoтизм какой-то. А что, какие-то де'Биллы и отдельному вахтеру за это платить готовы? oO

    > И с точки зрения производительности гонять по сети 24-битные картинки просто глупо.

    С умным сжатием - нормально вполне. Иногда 24-битная битмапа жмется даже лучше, от картинки зависит сильно.

     

  • 1.25, arisu (ok), 20:10, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    вот браузер-то обрадуется от картинки таких размеров! человек, видимо, не в курсе, что браузер пытается скачать в память ВСЮ картинку, а не «последние пять кадров».
     
     
  • 2.32, all_glory_to_the_hypnotoad (ok), 22:07, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    да нормально всё, будет пользоваьель раз в минут 30  перегружать браузер с виндовском, не привыкать
     
  • 2.39, Аноним (-), 07:25, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > что браузер пытается скачать в память ВСЮ картинку,

    А что, декомпресанутые и показанные кадры он не дропает? Если это так - можно конкретную такую декомпресс-бомбу изобразить.

    Хинт: генерим белую простыню, 100500х100500 пикселей (ну или сколько там гиф позволяет). Даже убогий LZW сожмет такое весьма во много раз. Пхаем 100500 кадров такого формата. Подпихиваем жертве. Смотрим что будет :)

     
     
  • 3.42, arisu (ok), 07:43, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А что, декомпресанутые и показанные кадры он не дропает?

    возможно, тут я перегнул: очень давно не видел незацикленых гифов, не уверен, как себя ведут браузеры с ними. буду, впрочем, сильно удивлён, если кому-то было настолько нечего делать, чтобы писать два варианта кода для обработки гифов — учитывая то, что большинство их них зацикленые. надо бы, конечно, глянуть исходники вебкита и гекона, но пардон — лень.

    опера, например, ведёт себя забавно: проигрывает гиф заново при каждой активации таба. вебкит и гекон так себя не ведут, но сохраняют ли все кадры — не знаю.

    > Хинт: генерим белую простыню, 100500х100500 пикселей (ну или сколько там гиф позволяет).
    > Даже убогий LZW сожмет такое весьма во много раз. Пхаем 100500
    > кадров такого формата. Подпихиваем жертве. Смотрим что будет :)

    если поставить бесконечную зацикленность — смешно очень будет. впрочем, подозреваю, что какие-то ограничения на всё это внутри движков стоят, иначе подобные бомбы давно уже по интернетам бы прыгали.

     
     
  • 4.46, Аноним (-), 01:20, 29/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну да, там несколько вариантов возможно Сжатый вариант наверное все прихраниваю... текст свёрнут, показать
     

  • 1.27, Аноним (-), 20:34, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всего 54 строчки кода. Инновационно!
     
     
  • 2.28, Аноним (-), 20:35, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Проект достойный Сколково!
     

  • 1.48, Andrey Sidorov (?), 10:05, 29/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    https://github.com/sidorares/vnc-over-gif/wiki/FAQ
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру