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
Instead of the audiodecoder one. The OMX audioo decoders have their
valid input in the template pad, so just check against that to
avoid doing a query downstream.
Instead of the videodecoder one. The OMX video decoders have their
valid input in the template pad, so just check against that to
avoid doing a query downstream.
When g_option_context_parse fails, context and error variables are not getting free'd
which results in memory leaks. Free'ing the same.
And replacing g_error_free with g_clear_error, which checks if the error being passed
is not NULL and sets the variable to NULL on free'ing.
https://bugzilla.gnome.org/show_bug.cgi?id=753865
The omxvideodecoder class only checks some of the caps parameters but if
other fields change such as h264 profile and/or level it wouldn't trigger a
reconfiguration.
https://bugzilla.gnome.org/show_bug.cgi?id=752376
Might come in handy, and these warnings seem to be
fatal in some environments.
You may need to git clean -x -d -f your tree before
git pulling/merging.
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
There is one rare case where calling handle_messages() more than once can cause a deadlock
in the video decoder element:
- sink pad thread starts the src pad task (gst_omx_video_dec_loop())
- _video_dec_loop() calls gst_omx_port_acquire_buffer() on dec_out_port
- blocks in gst_omx_component_wait_message() releasing comp->lock and comp->messages_lock
(initially, there are no buffers configured on that port, so it waits for OMX_EventPortSettingsChanged)
- the sink pad thread pushes a buffer to the decoder with gst_omx_port_release_buffer()
- _release_buffer() grabs comp->lock and sends the buffer to OMX, which consumes it immediately
- EmptyBufferDone gets called at this point, which signals _wait_message() to unblock
- the message from EmptyBufferDone is processed in gst_omx_component_handle_messages()
called from gst_omx_port_release_buffer()
- gst_omx_port_release_buffer releases comp->lock
- the src pad thread now gets to run, grabbing comp->lock while it exits from _wait_message()
- _acquire_buffer() calls the _handle_messages() on the next line after _wait_message(),
which does nothing (no pending messages)
- then it goes to "retry:" and calls _handle_messages() again, which also does nothing
(still no pending messages)
- scheduler switches to a videocore thread that calls EventHandler, informing us about the
OMX_EventPortSettingsChanged event that just arrived
- EventHandler graps comp->messages_lock, but not comp->lock, so it can run in parallel at
this point just fine.
- scheduler switches back to the src pad thread (which is in the middle of _acquire_buffer())
- the next _handle_messages() which is right before if (g_queue_is_empty (&port->pending_buffers))
processes the OMX_EventPortSettingsChanged
- the buffer queue is still empty, so that thread blocks again in _wait_message()
- the sink pad thread tries to acquire the next input port buffer
- _acquire_buffer() also blocks this thread in:
if (comp->pending_reconfigure_outports) { ... _wait_message() ... }
- DEADLOCK. gstreamer is waiting for omx to do something, omx waits for gstreamer to do something.
By removing those extra _handle_messages() calls, we can ensure that all the checks of
_acquire_buffer() will re-run. In the above case, after the scheduler switches back to
the middle of _acquire_buffer(), the code will enter _wait_message(), which will see that
there are pending messages and will return immediately, going back to "retry:" and
re-doing all the checks properly.
https://bugzilla.gnome.org/show_bug.cgi?id=741854
