Without this commit the decoder streaming thread stops without ever attending
the drain request, leaving the decoder input thread waiting forever.
https://bugzilla.gnome.org/show_bug.cgi?id=758274
ret is set to GST_STATE_CHANGE_SUCCESS and never touched, so it is impossible
for it to be anything else at the if check. Remove the if check.
CID #1287053
Fixes "GThread-ERROR **: file gthread-posix.c: line 171
(g_mutex_free_posix_impl): error 'Device or resource busy' during
'pthread_mutex_destroy ((pthread_mutex_t *) mutex)'" in _finalize.
Fix printf formats again, so that gst-omx compiles warning-
free on the Raspberry Pi as well. Unfortunately OMX_UINT32
maybe be typedefed to uint32_t or unsigned long, which
doesn't work well with our debugging printf format strings,
so just use %u for those and cast to guint.
No mutex is locked while calling any OpenMAX functions anymore
and everything from the OpenMAX callbacks is inserted into a message
queue and handled from outside the callbacks.
Also there's only a single mutex and condition variable per component
now for handling anything from OpenMAX callbacks and a single mutex
for keeping our component/port state sane.
According to the OMX specification, implementations are allowed to call
callbacks in the context of their function calls. However, our callbacks
take locks and this causes deadlocks if the unerlying OMX implementation
uses this kind of in-context calls.
A solution to the problem would be a recursive mutex. However, a normal
recursive mutex does not fix the problem because it is not guaranteed
that the callbacks are called from the same thread. What we see in Broadcom's
implementation for example is:
- OMX_Foo is called
- OMX_Foo waits on a condition
- A callback is executed in a different thread
- When the callback returns, its calling function
signals the condition that OMX_Foo waits on
- OMX_Foo wakes up and returns
The solution I came up with here is to take a second lock inside the callback,
but only if recursion is expected to happen. Therefore, all calls to OMX
functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(),
which effectively tells the mutex that at this point we want to allow calls
to _recursive_lock() to succeed, although we are still holding the master lock.
