RPi2, OpenMAX, тупик

Question

RPi2, OpenMAX, тупик

Среда

Raspberry Pi 2 B +
Debian Linux
OpenMAX IL

Использование регистра

OpenMAX Camera Видеозахват
- Порты камеры отключены
- Renderer / Camera Tunnel установлен
- Состояние всех компонентов установлено в состояние ожидания
- Порты включены

Описание проблемы

Первый порт подключается к порту ввода камеры (порт № 73), порт активируется с помощью команды «OMX_CommandPortEnable», так как с помощью команды «OMX_CommandPortDisable» компонент камеры должен запускать его «OMX_CALLBACKTYPE :: EventHandler »обработчик событий, имеющий« eEvent == OMX_EventCmdComplete »и« nData1 == OMX_CommandPortEnable », однако этого никогда не происходит, и приложение бесконечно ждет, пока порт станет активным.

Анализ проблем

Я использую std :: condition_variable в сочетании с std :: mutex для ожидания завершения изменения состояния, поэтому OMX_CALLBACKTYPE :: EventHandler обновляет условную переменную и вызывает «notify_one ()», пока поток вызывающей стороны блокирует std :: mutex и дождитесь, когда будет установлена переменная условия, при таком подходе OMX_CALLBACKTYPE :: EventHandler никогда не вызывается (с любым аргументом), и программа блокируется навсегда.
НОТА: При ожидании условной переменной проверяется, что мьютекс не принадлежит, это делается путем проверки (0 == std :: mutex :: __ owner).
ТЕМ НЕ МЕНИЕ, Все отлично работает при опросе состояния порта путем итеративного вызова usleep и OMX_GetParameter (OMX_IndexParamPortDefinition).

Вопрос под рукой

Почему «OMX_CALLBACKTYPE :: EventHandler» срабатывает при опросе его значения и НЕ срабатывает при использовании условной переменной? С окнами есть понятие APC & Оповещаемые темы, есть ли эквивалент в Linux? Тот, который может объяснить вышеупомянутое?

1

c++linux multithreading openmax raspberry-pi

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Мой опыт показывает, что включение порта не вызывает обратный вызов события, пока порт не будет заполнен буферами. То есть последовательность:

Установить порт на включенный (OMX_SendCommand() с OMX_CommandPortEnable).
Заполнить буферы порта (OMX_AllocateBuffer() или же OMX_UseBuffer()).
Получать OMX_CommandPortEnable обратный вызов

Если вы дождетесь обратного вызова события, прежде чем выделите буферы, у вас будет тупик.

Когда вы проводите опрос с помощью тестирования OMX_PARAM_PORTDEFINITIONTYPE.bEnabledсобирается вернуться OMX_TRUE немедленно, потому что спецификация говорит, что этот элемент установлен синхронно:

Порт должен немедленно установить bEnabled в своем определении порта
структура, когда порт получает OMX_CommandPortEnable,

Вот что я думаю, что происходит для вас, когда все «работает»:

Установите порт на включен.
Опрос пока bEnabled является OMX_TRUE (что происходит сразу).
Заполните буферы порта.
Получать OMX_CommandPortEnable обратный вызов

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

Установите порт на включен.
Опрос пока bEnabled является OMX_TRUE (что происходит сразу).
Получать OMX_CommandPortEnable обратный вызов
Заполните буферы порта.

Это создает впечатление, что использование условной переменной как-то меняет поведение OpenMAX. В действительности bEnabled и OMX_CommandPortEnable обратный вызов на самом деле не сообщают об одном и том же. Я не верю, что какая-либо синхронизация необходима (или желательна) между включением порта и распределением его буферов.

1