2010-08-19 2 views
3

Я экспериментирую с разработкой инструмента для удаленного рендеринга OpenGL на C++. Основная идея заключается в том:OpenGL визуализировать передачу в реальном времени

  1. клиент выдает команды OpenGL, как это нормальное приложение
    • Эти команды фактически передаются по сети к внешнему серверу
    • сервер выполняет рендеринг с помощью некоторых OFF- экранная техника
    • После этого сервер передает клиенту один кадр по сети
    • Клиент отображает рамку на экране.
    • Петля.

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

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

У меня на правильном пути об этом? Правильно ли здесь использовать библиотеку потокового видео? Если вы так думаете, какая хорошая библиотека для этой задачи (в C или C++, желательно C++)?

Благодарим за помощь!

+2

Какая разница с существующими инструментами (X11, ssh -X, VNC, VirtualGL)? – Calvin1602

+0

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

+0

Похоже на полпути к чему-то вроде [OnLive] (http://en.wikipedia.org/wiki/OnLive) и др. Возможно, стоит посмотреть на статьи о них. –

ответ

1

У вас есть два решения.

Решение 1

  • запустить приложение удаленно
  • перехватывать OPENGL называет
  • переслать их по сети
  • Выдайте OPENGL называет, локальной

-> сложно, особенно при работе с буферами и текстурами; реальный код openGL выполняется локально, что может быть не так, как нужно, но это зависит от вас.Более того, он прозрачен для удаленного приложения (без изменения источника, без перестройки). Почти нет сетевого общения.

Решение 2: то, что вы описали, с плюсами и минусами.

Если вы решите проблему 2, не беспокойтесь о скорости на данный момент. Поверьте мне, у вас будет достаточно проблем с openGL.

Начнет с синхронным режимом: рендер, получать, передавать, рендер, принести, отправить Затем в асинхронном режиме: рендеринг, начать выборки, визуализация, конец выборки, начать отправку, визуализация и т.д. Это будет быть достаточно сложным, я думаю,

0

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

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

Вот некоторые из интересных тем, которые я читал, и, надеюсь, они будут пролить свет на эту тему:

Video streaming using c++

How do I stream video and play it?

1

В зависимости от разрешения, которое необходимо поддерживать, и скорости вашей локальной сети, может быть возможно передавать несжатые данные.

Для 24-разрядного кадра 1280x1024 требуется 30 Мбит, а с гигабитным Ethernet это означает, что теоретический 33 кадра в секунду несжатый.

Если этого недостаточно, добавление простого RLE-сжатия осуществляется довольно просто.