環境
- ラズベリーパイ2B+
- Debian Linux
- OpenMAX IL
使用事例
- OpenMAX カメラ ビデオ キャプチャ
- カメラ ポートが無効になっています
- Renderer / Camera Tunnel を設定
- すべてのコンポーネントの状態が Idle に設定されています
- ポートが有効になっています
問題の説明
最初のポートはカメラ入力ポート (ポート #73) に対して有効になっています。このポートは、「OMX_CommandPortEnable」コマンドを使用して有効にされています。「OMX_CommandPortDisable」コマンドと同様に、カメラ コンポーネントが「OMX_CALLBACKTYPE::」を起動することが期待されます。 「eEvent == OMX_EventCmdComplete」および「nData1 == OMX_CommandPortEnable」を持つ EventHandler」イベント ハンドラーの場合、これは発生せず、アプリケーションはポートが有効になるまで無限に待機します。
問題分析
std::mutex と組み合わせて std::condition_variable を使用して、状態の変更が完了するのを待ちます。したがって、OMX_CALLBACKTYPE::EventHandler は条件変数を更新し、呼び出し側スレッドが std::mutex をロックしている間に「notify_one()」を呼び出します。このアプローチを使用して、条件変数が設定されるのを待ちます。「OMX_CALLBACKTYPE::EventHandler」は (引数を指定して) 呼び出されることはなく、プログラムは永久にロックされます。
注: ミューテックスが所有されていないことが検証される条件変数を待機する場合、これは (0 == std::mutex::__owner) を検証することによって行われます。
ただし、 usleepと OMX_GetParameter(OMX_IndexParamPortDefinition) を繰り返し呼び出してポートのステータスをポーリングすると、すべて正常に動作します。
手元にある質問
「OMX_CALLBACKTYPE::EventHandler」が値のポーリング時にトリガーされ、条件変数の使用時にトリガーされないのはなぜですか? Windows には APC & Alertable スレッドの概念がありますが、Linux に同等のものはありますか? 上記を説明できる人はいますか?