Ensure that enough buffers are allocated by adding up component's own
minimal plus the number of buffers requested by downstream.
This should prevent buffers starvation problem if downstream elements
are holding some of the buffers they required.
Also simplify the check on the maximum on buffers. What we actually care
about is to make sure the pool can hold the minimum of required buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=784479
Some platforms may not implement OMX_IndexConfigVideoAVCIntraPeriod and
use OMX_IndexParamVideoAvc instead to configure the GOP pattern.
So raise a warning instead of an error if this API is not implemented.
https://bugzilla.gnome.org/show_bug.cgi?id=784379
The decoder only requires to receive one frame per buffer which is
already enforced with 'alignment=au'. There is no need to require to
have a parser upstream.
Allow to run "encode ! decode" pipeline without having a parser.
https://bugzilla.gnome.org/show_bug.cgi?id=784344
The OMX specification defines two API to set the AVC profile and level:
using OMX_VIDEO_PARAM_PROFILELEVELTYPE and OMX_VIDEO_PARAM_AVCTYPE.
We were already supporting the former but not the latter. We are now
setting both so implementation don't have to rely on a specific one.
https://bugzilla.gnome.org/show_bug.cgi?id=783862
The OMX_VIDEO_CONFIG_AVCINTRAPERIOD.nPFrames setting isn't of any use on
the raspbery pi. Instead it uses a custom extension to define the I
frame period.
https://bugzilla.gnome.org/show_bug.cgi?id=783829
Previously the omx plugin was blacklisted if GST_OMX_CONFIG_DIR
points to an invalid path or if the gstomx.conf contains 0 valid
component.
Problem is that once the plugin is blacklisted, a rescan is not
triggered upon changes of the env var or the gstomx.conf file
despite being setup with gst_plugin_add_dependency.
This also makes it more consistent with other plugins that auto
generate features. For example gst-{ffmeg,libav}, gstreamer-vaapi,
v4l2 video dec.
To clarify the diff, the plugin_init func will return TRUE even if
g_key_file_get_groups returns 0 element and even if
g_key_file_load_from_dirs fails.
https://bugzilla.gnome.org/show_bug.cgi?id=782867
gstomxvideoenc.c: In function ‘gst_omx_video_enc_fill_buffer’:
CC libgstomx_la-gstomxaacdec.lo
gstomxvideoenc.c:1316:27: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 8 has type ‘OMX_U32 {aka long unsigned int}’ [-Wformat=]
GST_LOG_OBJECT (self, "Matched strides - direct copy %u bytes",
^
outbuf->omx_buf->nFilledLen);
~~~~~~~~~~~~~~~~~~
egl_render seems to have a bug and signals EOS before it has finished
pushing out all data; this hack simply makes acquire_buffer() wait
a bit more before signalling EOS, in case egl_render decides to spit
out some more data.
https://bugzilla.gnome.org/show_bug.cgi?id=741856
gstomx.c:1376:42: error: implicit conversion from enumeration type 'GstOMXAcquireBufferReturn' to different enumeration type 'OMX_ERRORTYPE'
(aka 'enum OMX_ERRORTYPE') [-Werror,-Wenum-conversion]
g_return_val_if_fail (!port->tunneled, GST_OMX_ACQUIRE_BUFFER_ERROR);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
https://bugzilla.gnome.org/show_bug.cgi?id=775112
GST_VIDEO_FRAME_PLANE_STRIDE() should be used to get the actual buffer stride,
as reported in the buffers's GstVideoMeta, when copying data to that buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=768173
Modified to use gstglmemoryegl to avoid texture creation/copy operations
at the glupload.
[Matthew Waters]: gst-indent the sources and port testegl to GstGLMemoryEGL
https://bugzilla.gnome.org/show_bug.cgi?id=760918
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.
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
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
Interlaced stream could make the decoder use two input frames to produce
one output frame causing the gstvideodecoder frame list to grow.
Assuming the video decoder output frame in display order rather than in
decoding order, this commit add a way to release frames with PTS less
than current output frame.
https://bugzilla.gnome.org/show_bug.cgi?id=730995
