Как TeamViewer так быстро?

Ответ 1

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

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

Производительность DirectX 3D в 1 FPS, похоже, в некоторой степени подтверждает мои предположения.

Ответ 2

потребуется время для маршрутизации через сервер TeamViewer (TeamViewer обходит корпоративные Symmetric NAT, просто проксируя трафик через свои серверы)

Вы обнаружите, что TeamViewer редко нуждается в ретрансляции трафика через свои собственные серверы. TeamViewer проникает в NAT и сети, сложные NAT с использованием NAT traversal (я думаю, что это UDP отверстие-перфорация, например Google libjingle).

Они используют свои собственные серверы для среднего человека, чтобы выполнить рукопожатие и настройку соединения, но большую часть времени отношения между клиентом и сервером будут P2P (лучший случай, когда успешное дрожание рук). Если обход NAT не удался, TeamViewer действительно будет передавать трафик через свои собственные серверы.

Я только когда-либо видел это, когда клиент был за двойным NAT.

Ответ 3

Немного поздний ответ, но я предлагаю вам взглянуть на малоизвестный проект на codeplex под названием ConferenceXP

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

Предоставляется полный источник (он огромный!). Он реализует протокол RTP.

Ответ 4

Звучит действительно как потоковая передача видео больше, чем потоковое изображение, как кто-то предложил. Сжатие JPEG/PNG не предназначено для этих типов скоростей, поэтому забудьте их.

Представьте, что в вашей системе есть записывающий кодек, который в реальном времени может записывать входящий видеопоток (ваш экран). Возможно, немного похоже на Фрэпса. Затем представьте себе кодек воспроизведения видео с другой стороны (удаленный клиент). Поскольку HD-рекордеры могут это сделать (запись в прямом эфире и даже воспроизведение в реальном времени с одного и того же HD), так и вы, в конце концов. HD, безусловно, не может доставлять изображения быстрее, чем вы можете читать свой дисплей, так что это не узкое место. Узким местом являются видеокодеки. Вы обнаружите, что кодер гораздо больше проблем, чем декодер, поскольку все декодеры в основном свободны.

Я не говорю это просто; Я сам использовал DirectShow для кодирования видеофайла, и это не в реальном времени. Но, учитывая правильный кодек, я убежден, что он может работать.

Ответ 5

Как ни странно. но по моему опыту TeamViewer работает не быстрее/быстрее, чем VNC, его проще настроить. У меня есть пара win-boxen, в которой я VNC над OpenVPN (так что есть еще один верхний слой), и что на дешевом Cable (512 up), и я считаю, что правильно настроить TightVNC гораздо лучше, чем TeamViewer, на тот же самый boxen. RDP (естественно), тем более, что в значительной степени он отправляет команды рисования GUI вместо растровых фрагментов.

Что приводит нас к:

• Почему вы не используете VNC? Существует множество открытых источников решения и Tight, вероятно, на вершине этой игры прямо сейчас.

• Усовершенствованные реализации VNC используют сжатие с потерями и, как представляется, лучшие результаты, чем ваш выбор PNG. Кроме того, IIRC остальная часть полезной нагрузки также раздавлен с использованием zlib. Bothj Tight и UltraVNC имеют очень оптимизированные альго, особенно для окон. В дополнение к этому Tight является открытым исходным кодом.

• Если win boxen является вашей основной целью, RDP может быть лучшим вариантом и имеет реализацию с открытым исходным кодом (rdesktop)

• Если * nix boxen является вашей основной целью, NX может быть лучшим вариантом и имеет реализацию с открытым исходным кодом (FreeNX, хотя и не так оптимизирован как собственный продукт NoMachine).

Если сжатие JPEG является проблемой производительности для вашего алгоритма, я уверен, что сравнение изображений по-прежнему приведет к снижению производительности. Бьюсь об заклад, они используют сжатие наилучшего случая для каждой конкретной ситуации, т.е. С потерями для больших кадров, некоторые быстрые и грязные внутренние без потерь для меньших, сравнивают бит изображений и отправляют только разницы в сортировке и связке других трюков оптимизации.

И многие из этих трюков должны присутствовать в Tight > 2.0, так как снова, по моему опыту, он превосходит по производительности TeamViewer wyse, YMMV.

Кроме того, выбор скомпилированной среды выполнения JIT над чем-то вроде С++ может занять кусочек от вашего предела производительности, особенно в машинах с ограниченными физическими возможностями (при настройке в окнах интенсивно запускается настройка производительности в туалете). И вам понадобится память, чтобы сохранить предыдущие состояния изображения для внутреннего сравнения поверх того, что дает вам DF мираж.