Posts: 16
Joined: Mon Dec 07, 2015 4:27 am

OpenMAX deadlock, EventHandler is never called

Thu Dec 31, 2015 11:18 am

  • Raspberry Pi 2 B+
  • Debian Linux
  • OpenMAX
  • OpenMAX Camera Video capture
  • Camera ports are disabled
  • Renderer / Camera Tunnel is set
  • All components state is set to Idle
  • Ports are enabled
Problem description
The first port being enabled is the Camera Input port ( Port #73 ), the port is being enabled using the “OMX_CommandPortEnable” command, as with the “OMX_CommandPortDisable” command, it is expected for the camera component to fire it’s “OMX_CALLBACKTYPE::EventHandler” event handler having “eEvent == OMX_EventCmdComplete” and “nData1 == OMX_CommandPortEnable”, however, this never happen, “OMX_CALLBACKTYPE::EventHandler” is never called ( with any argument ) and the application infinitely wait for the port to become enabled.

Problem Analysis
I am using std::condition_variable in conjunction with std::mutex to wait for the state change to complete, hence, OMX_CALLBACKTYPE::EventHandler updates the condition variable and calls “notify_one()” while the caller thread locks std::mutex and wait for the condition variable to be set, using this approach “OMX_CALLBACKTYPE::EventHandler” is never called and the program locks forever.
NOTE: When waiting for the condition variable the mutex is verified not to be previosly owned, this is done by verifying (0 == std::mutex::__owner)
HOWEVER, All works fine ( and “OMX_CALLBACKTYPE::EventHandler” is triggered ) when polling the status of the port by calling usleep and OMX_GetParameter(OMX_IndexParamPortDefinition) iteratively.

Question at hand
Why is “OMX_CALLBACKTYPE::EventHandler” triggered when polling it’s value and NOT triggered when using a conditional_variable? With windows there is the notion of APC & Alertable threads, is there any equivalent in linux? One that can explain the above mentioned?

Posts: 16
Joined: Mon Dec 07, 2015 4:27 am

Re: OpenMAX deadlock, EventHandler is never called

Thu Dec 31, 2015 1:33 pm

If appears, that specifically for the camera input port ( #73 ) the port must have it's buffers allocated ( OMX_AllocateBuffer ) before the corresponding “OMX_CALLBACKTYPE::EventHandler” is invoked, and thus, no other than the following flow of actions must be taken:
  • OMX_SendCommand(OMX_CommandPortEnable)
  • OMX_AllocateBuffer
  • Wait for “OMX_CALLBACKTYPE::EventHandler” indicating the port was enabled
w/o calling the appropriate 'OMX_AllocateBuffer' a corresponding “OMX_CALLBACKTYPE::EventHandler” is never triggered
w/o calling "OMX_SendCommand(OMX_CommandPortEnable)" "OMX_AllocateBuffer" will always fail

My Question, is the above present some sort of an OS bug, OR, is it the expected behavior ?

Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6995
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: OpenMAX deadlock, EventHandler is never called

Mon Jan 25, 2016 10:11 pm

Read the spec - enabling the port requires that all buffers are allocate too. The command hasn't completed until it has a full complement of buffers, so intended behaviour.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Return to “OpenMAX”