Ответ 1

Интересная проблема. Есть несколько аспектов, которые следует учитывать в конкретном порядке:

Кодирование и потоковое воспроизведение в то же время

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

Кажется, что формат F4V (преемник FLV от Adobe) подходит для законопроекта, так как он может быть написан в потоковом режиме. Этот формат широко поддерживается клиентами, вам просто нужно установить плагин Flash Player. Для iPhone/iPad вам понадобится еще одна альтернатива, которая не связана с Flash, поэтому для iOS вы можете использовать MP4. Обратите внимание, что F4V происходит от MP4, оба они очень похожи.

Конечно, 3D-движок, работающий на сервере, должен будет иметь возможность отображать F4V/MP4, и для этого может потребоваться настраиваемый экспортный плагин.

Производительность

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

Задержка

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

Буферизация на стороне клиента

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

Поддержка сервера HTTP

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

Здесь может быть полезен выделенный потоковый сервер. Интересными являются ссылки с открытым исходным кодом Darwin Streaming Server и QuickTime Broadcaster потоковое приложение. Для стороны Adobe есть Adobe Streaming Server, который является коммерческим продуктом. И еще один вариант от Microsoft, расширение Smooth Streaming для IIS.

Интерактивность

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

Ответ 2

Не может быть эффективного решения этой проблемы в программном обеспечении... но, вероятно, есть аппаратное обеспечение: http://yhst-128017942510954.stores.yahoo.net/cube200-1ch-hdmi-enc2001.html

Должно быть возможно совместить кодировщик H.264, используемый этим устройством, с видеокартой с гораздо меньшими затратами.

Ответ 3

Видео с кодировкой потока

Подходы

Я работаю над подобной проблемой, и я расскажу то, что узнал. Хотя я не знаю, как их выпустить, я знаю, как создавать и кодировать несколько видео потоков HD на сервере. Я протестировал два подхода: NVIDIA API-интерфейс CUDA Video Encode (C Library) и tel. Примитивы Video Encoder. Ссылка NVIDIA вернет вас к примеру. На странице Intel нет внутренних якорей, поэтому вам придется искать "Video Encoder".

Настройка тестирования

Оба кодируют видеопотоки, вплоть до и вкл HD, до H.264. Поддерживаются другие форматы, но меня интересует H.264. Чтобы проверить производительность, я настроил готовое входное видео в формате YUV и подал его в кодировщики так быстро, как они могли бы его принять. Выходной сигнал обоих кодеров составлял 1080P.

Производительность процессора

Производительность, видеокодер Intel может кодировать один поток в режиме реального времени 0,5X с нагрузкой 12,5% на Xeon E5520 @2,27 ГГц, то есть на одно ядро ​​из восьми при 100% нагрузке. Новые Xeon намного быстрее, но я не знаю, смогут ли они в реальном времени попасть в реальное время.

Производительность графического процессора

Кодер NVIDIA на GTS 450 может кодировать 9-10X в реальном времени 1080P (!) с нагрузкой процессора 50%. Нагрузка процессора на NVIDIA, по-видимому, в первую очередь копирует данные на GPU и обратно.

Что особенно приятно в решении GPU, так это то, что он может воспринимать поверхность рендеринга GPU как входную; графики генерируются и кодируются на графическом процессоре, оставляя их только для выхода в сеть. Подробнее об использовании поверхности рендеринга и ввода см. CUDA by Example, отличную и прямолинейную книгу по программированию на GPU. В этом случае я ожидаю, что загрузка процессора упадет примерно наполовину. Поскольку нет смысла двигаться быстрее, чем в реальном времени для графики в реальном времени, вы, вероятно, можете кодировать 8+ потоков из поверхностей рендеринга с соответствующими ресурсами графического процессора, например. две карты GTS 450, возможно, намного больше, если разрешение ниже 1080P приемлемо.