Gstreamer - Как структурировать приложение с несколькими src? - PullRequest
Новая
       13

Gstreamer - Как структурировать приложение с несколькими src?

8 голосов
/ 11 мая 2019

У меня есть ситуация, когда у меня несколько камер (rtspsrc) и одноэлементный элемент, который выполняет аналитику входящего видеопотока.Я называю это одноэлементным элементом, потому что он имеет источник запроса и контактные площадки.В приложении должен существовать только один из них, поскольку он работает на графическом процессоре и может повысить производительность, выполняя пакетные операции.Представьте, что приложение, которое я создаю, представляет собой API-интерфейс для добавления камер, удаления камер, включения и выключения аналитики для каждой камеры и т. Д. На камерах будет выполняться аналитика, фиксировать результаты и отправлять их дальше.Сложность заключается в том, что мне нужно поделиться элементом Gstreamer (аналитическим элементом).

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

  • Пауза определенной камеры
  • Каждая rtspsrc должна быть полностью изолирована, поэтому ошибки в одной из них не влияютвесь конвейер
  • Прослушивание событий на определенной камере

Если у меня все камеры в конвейере вместе, я не могу понять, как приостановить конкретную камеру.Я не могу приостановить весь конвейер, потому что это остановит все камеры.Лучшее, что я придумал, - это удалить и в отличие от элементов для определенных камер, а затем при возобновлении добавить и заново связать.Это работает вроде.Если определенный rtspsrc перестает отвечать, тогда останавливается весь конвейер.Если конкретный rtspsrc не существует, тогда весь конвейер не перейдет в состояние PLAYING

Как мне разработать свое приложение?Как вы думаете, у меня должен быть один большой трубопровод?Или я должен иметь конвейер, содержащий элемент одноэлементной аналитики, и конвейер для каждой камеры, а затем соединить их с помощью appsink и appsrc?Такой подход может упростить обработку, поскольку каждый конвейер полностью отделен?

Дайте мне знать, если вам нужна дополнительная информация.

Ответы [ 2 ]

2 голосов
/ 19 мая 2019

Учитывая ваши требования, я построил бы большую часть API, управления камерой и GUI в c #, с шаблоном MVVM и контейнером DI, чтобы вы как можно больше разделяли свои части API и делали их максимально тестируемыми.Еще одна причина заключается в том, что с этой экосистемой очень быстро создать пользовательский интерфейс (C #, Visual Studio);также для большинства проектов вы знаете, что техническое обслуживание будет основной стоимостью Стоимость разработки в сравнении со стоимостью обслуживания , следовательно, развязка и тестирование на интерфейсах превосходны, чтобы поддерживать эти затраты как можно ниже .;MVVM позволит вам протестировать ваш пользовательский интерфейс Написание тестируемого уровня презентации с MVVM .Разделение компонентов программного обеспечения также позволит вам обновить определенную реализацию, не касаясь остальных, и скомпоновать свое программное обеспечение с его компонентами в корне композиции .Часто такие практики позволяют начинать с тестов (TDD).

Я бы позаботился о том, чтобы на каждую камеру было по 1 конвейеру, чтобы упростить управление ресурсами, и если вы используете cudastreams ( cudastreams для упрощения параллелизма ), вы можете иметь несколько задач видеоаналитики на одном графическом процессоре, каждый поток выполняет аналитику видео потока одной камеры.Возможно, вы захотите использовать проверенный код из opencv и убедиться, что он может быть передан в виде потока.Если объем данных, ваши требования к производительности и вашему оборудованию не понадобятся / не позволят такой вещи, вы можете просто использовать одну обработку opencv.

В нативной части (gstreamer) интерфейс относительно прост в настройке.компоненты с C # с взаимодействием;например: 

extern "C" __declspec(dllexport) auto Query(myClass* p, const wchar_t* somePath)
    -> structResult*
{ return p->Query(somePath); }

и в управляемой части: 

[DllImport("myAssembly.dll", CallingConvention = CallingConvention.Cdecl)]
internal static extern IntPtr Query(IntPtr myClassPointer, IntPtr somePath);
1 голос
/ 19 мая 2019

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

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

...