Захват видео + загрузка + обработка + обратная потоковая передача - .NET и C #

Я бы сделал это так:

1. Используйте silverlight или вспышку для захвата входа видеокамеры, например как подробно здесь.
2. Вы можете отправить поток байтов через сокет, который слушает ваш сервер.
3. На принимающей стороне просто используйте программу, принимающую сокеты, как программу-маршрутизатор с несколькими подключенными слушающими рабочими процессами. Между рабочими процессами и программой-маршрутизатором, например AMQP с RabbitMQ. Отправляйте асинхронные сообщения (например, с реактивными расширениями), например, кодирование потока на узел-кролик, который затем может передавать все сообщения на один компьютер в рамках беседы / пользовательского сеанса или чередовать доступные рабочие. Вот руководство. По мере того, как видео кодируется, оно асинхронно передается обратно по шине сообщений. Согласно тестам Intel, сама шина должна хорошо работать на высокой пропускной способности, но они должны были использовать режим чередующегося tcp-канала (они тестировали на гигабитной локальной сети). Другие пользователи здесь предложили FFlib. Вы также можете подумать о преобразовании воркеров в webM, но если FFlib работает, это может быть намного проще . Каждый работник публикует через AMQP следующий закодированный фрагмент видео. Программа, работающая на сервере, например программа-маршрутизатор, о которой я говорил ранее, начинает отправлять клиенту (см. № 4)
4. Имейте клиентскую программу, например silverlight / flash (например, через тот же сокет, который вы открыли для данных клиент-> сервер, или через HTTP) и считайте поток байтов с помощью декодера. Визуализируйте результат.

VideoLab от Mitov может выполнить все это и бесплатно для личного использования (не так бесплатно для коммерческого использования, но цена не слишком высока).

Я купил и использую версию Delphi и знаю, что она работает очень хорошо, поэтому я почти уверен, что версия .NET сделает то, что вам нужно.

Задача такого рода нетривиальна (как видно по отсутствию здесь ответов), поэтому ожидайте значительных проблем с DirectX / Microsoft Media Encoder, но с этим набором инструментов и некоторой помощью автора вы получите в итоге получится.

http://www.mitov.com/html/videolab.html

Кажется, что Splicer может обрабатывать статическое видео и преобразовывать его - я не уверен в обработке видео, загруженного в реальном времени - http://splicer.codeplex.com/

Взгляните на Video.Show от Головокружение. Это веб-сайт с открытым исходным кодом для пользовательского видеоконтента. Он использует Expression Encoder для обработки сжатия / редактирования видео. Это не совсем то, что вам нужно, но это хорошее начало!

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

В нем должно быть все необходимое:

Интеллектуальное кодирование / интеллектуальное повторное сжатие для WMV, если источником также является WMV и не выполняются операции с кадрами [4], редактирование сокращений, последовательное пакетное кодирование, кодирование в реальном времени с веб-камер и видеокамер DV

Поддержка формата декодирования / импорта из-за DirectShow

Плавная потоковая передача (720p + видео с использованием HTTP) с оптимизированным клиентом (Silverlight) и сервером (IIS с плавной потоковой передачей)

Публикация WebDAV, плагины публикации для Silverlight Streaming, Amazon S3

Импорт наложений XAML, созданных в Expression Design, и настройка их времени, анимации, непрозрачности, размещения и зацикливания

События триггера JavaScript

Интеграция Windows Media 11 SDK и VC-1 SDK, собственный декодер MPEG-2

Добавление подписей к видео в формате SAMI или W3C Timed Text

Предварительный просмотр и сравнение настроек кодировки в реальном времени

Скриншот

Объектная модель для механизма кодирования, SDK загружается отдельно

Вопрос вкратце о деталях (это веб-сервер, какая операционная система является сервером?

Вы можете подумать об одновременном выполнении захвата и обработки. Если пользователь запускает ваше клиентское приложение, сделайте захват и обработку через DirectShow. Затем все, что вам нужно сделать, это загрузить видео, и вы можете пропустить весь процесс сервера. Предполагается, что «пользователь» находится под вашим контролем - что это не какой-то случайный человек, загружающий видео, а сотрудник или кто-то, кому вы доверяете.

Если это не так, то ffmpeg, безусловно, можно использовать для водяных знаков на вашем сервере. На самом деле вам не нужны «обертки». Вы можете просто вызвать его как приложение командной строки из своего серверного приложения и дождаться его завершения.

Процесс на самом деле не так уж сложен ... важны его детали (например, что для вас значит слово "поток"? Вы действительно имеете в виду "поток" или это через http ? Это огромная тема прямо там)