Как перенаправить вывод приложения directshow (C ++) в приложение C#? - PullRequest
1 голос
/ 06 мая 2020

Я делаю приложение C# для захвата графики c с карты захвата avermedia p cie. Но похоже, что для этого нет готовых инструментов. Поэтому я создал приложение Directshow на C ++ для захвата, которое является консольным приложением и открывает окно захвата при запуске. Как я могу перенаправить вывод в приложение C#? например, в CaptureElement?

1 Ответ

0 голосов
/ 07 мая 2020

Итак, вы хотите, чтобы XAML CaptureElement был подключен к карте захвата AverMedia P CIe. В целом это звучит как хорошо понятная задача, однако все остальные упомянутые вами технологии в конечном итоге являются плохим выбором: DirectShow, несколько приложений с конвейером, перенаправление и подгонка кода сокращения к элементу управления XAML CaptureElement.

Microsoft имеет намеренно были ограничены способы интеграции различных API, поэтому существует не так много способов собрать все вместе.

Давайте go по предполагаемому пути интеграции. Карта захвата должна поставляться с совместимым драйвером:

Устройства видеозахвата поддерживаются драйвером класса UV C и должны быть совместимы с UV C 1.1

В этом случае такие устройства видны для Media Foundation API, обрабатывающего захват видео среди задач. XAML CaptureElement сможет видеть устройство видеозахвата через этот API, и таким образом все должно работать без необходимости подгонять что-либо с вашей стороны.

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

Предыдущий медиа-API в Windows был DirectShow, но его дни прошли. Он по-прежнему отлично работает как устаревший фреймворк, многие приложения по-прежнему полагаются на него. В частности, он не будет интегрирован с новыми технологиями, такими как XAML и UWP. Более того, даже сама Media Foundation, текущий медиа-API, в своем предложении publi c отстает, когда дело доходит до соответствия новейшим технологиям. Сказав, что здесь неплохо держаться подальше от DirectShow, если это вообще возможно.

Я не вижу необходимости в кросс-процессном проектировании с передачей видео между процессами по конвейеру. Для такой конструкции нет веских причин, и хотя она может работать эффективно (Windows само по себе доказывает, что она может отлично работать с точки зрения производительности, имея в себе так называемую службу Frame Server), это не должно быть построено на конвейере. В вашем случае вряд ли придется строить на нескольких процессах. Вместо этого вы можете разработать проект DLL с собственным кодом, который позаботится о получении видео и подключается к управляемому коду через подходящий связующий слой: C ++ / CLI, COM, C ++ / WinRT и т. Д. CaptureElement. Элемент управления разработан для работы с классом Windows.Media.Capture.MediaCapture, который взаимодействует с оборудованием, и у вас нет подходящего оборудования, поскольку вы планируете реализовать свой собственный уровень сбора данных. Короче говоря, вы не должны пересылать внешние данные в CaptureElement, и вам будет сложно это сделать. Лучшая стратегия - загрузить данные, полученные извне, в Windows.Graphics.Imaging.SoftwareBitmap или аналогичный, и принять соответствующее влияние на производительность как приемлемое. То есть вы будете иметь дело с видеокадрами как с изображениями.

Альтернативный способ - загрузить полученные видеокадры в текстуры Direct 3D 11, и это откроет вам более эффективный способ интеграции с элементами управления видео, такими как Windows.UI.Xaml.Controls.SwapChainPanel, однако для этого также потребуется там больше усилий по развитию.

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