No semantic change, just factor out the code enabling and disabling the
component to their own functions.
Makes the code easier to read as the set_format() method was already
pretty big. Will also allow us to easily change the enabling logic.
https://bugzilla.gnome.org/show_bug.cgi?id=785967
Will be easier to maintain and to make enhancements.
Tested with Tizonia on Desktop.
Also tested with Bellagio to make sure it does not crash when
calling OMX_UseEGLImage and indeed it returns NotImplemented.
Then gst-omx fallback to OMX_UseBuffer if it can and so on.
Also tested on rpi to make sure there is no regression.
https://bugzilla.gnome.org/show_bug.cgi?id=784365
On segment seek, unlike EOS, we drain, but we cannot expect a flush
later to reset the decoder state. As a side effect, the decoder would
remain in EOS state and ignore any new incoming buffers.
To fix this, we call _flush() inside the _drain() function, and
_finish() becomes what _drain() was before. This way, for _finish() (the
eos case) we only drain, for _drain() triggered by segment seek or new
caps, we also reset the decoder state so it's ready to accept buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=785237
The zynqultrascaleplus OMX implementation has a custom extension
allowing decoders to output dmabuf and so avoid buffers copy between OMX
and GStreamer.
Make use of this extension when built on the zynqultrascaleplus. The
buffer pool code should be re-usable for other platforms as well.
https://bugzilla.gnome.org/show_bug.cgi?id=784847
It triggers SettingsChanged on the other port and it is up to
the client to decide if it should lead to a port reconfiguration.
Settings are propagated to the other port for fields they have
in common. But this event is only triggered on the other port
if it actually change a setting.
https://bugzilla.gnome.org/show_bug.cgi?id=783976
Can happen if gst_buffer_pool_acquire_buffer succeeds but
gst_buffer_n_memory (buffer) is not exactly 1.
In theory this should not happen because the decoder requests
EGLImage(RGBA) but better to fix any leak on corner cases.
https://bugzilla.gnome.org/show_bug.cgi?id=784365
For example this allows the omx decoder to directly fill the
pixmaps coming from the video sink.
It only avoids a buffer copy when the decoder uses a pool provided
by a downstream element. So let's restrict this usage to situations
where the decoder decides to use a downstream buffer pool.
Tested with Tizonia/OMX.Aratelia.video_decoder.vp8
and with Bellagio/OMX.mesa.video_decoder.avc.
If it fails to setup buffers with OMX_UseBuffer the decoders
fallbacks to usual OMX_AllocateBuffer.
Also it allows to test on desktop the GstOMXBufferPool->other_pool
management which was previously only used in the OMX_UseEGLImage
case, i.e. on Rpi.
https://bugzilla.gnome.org/show_bug.cgi?id=784069
gst_omx_video_dec_open will only update GstOMXVideoDec->port->port_def.
Note that the component is reopen only if the flag
GST_OMX_HACK_NO_COMPONENT_RECONFIGURE is set.
https://bugzilla.gnome.org/show_bug.cgi?id=782418
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
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 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.
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
Previously when using gst EGLImage allocator the caps was
video/x-raw, format=RGBA instead of
video/x-raw(memory:EGLImage), format=RGBA
Kepp previous behavior in case negotiation fails with caps feature.
It means it will still have a chance to use EGLImage even if the
feature is not in the caps.
https://bugzilla.gnome.org/show_bug.cgi?id=729196
Identical functionality spread of two different components.
We can't use a common base class because of different inheritance,
but let's try to share the code anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=726024
No need to make it more complicated and error prone than
necessary. Also give the function a gst_omx_video_dec prefix
to distinct it from the encoder function.
https://bugzilla.gnome.org/show_bug.cgi?id=724236
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.
We will get exactly one frame per input buffer and assigning
timestamps between frames if more than one OMX buffer is required
per frame easily confuses timestamp tracking in OMX.
