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
This information can be useful to zynqultrascaleplus decoders. They may
use this information to reduce startup latency by configuring itself
before receiving the first frames.
We also have a custom OMX extension allowing the decoder to report the
latency. The profile/level information helps it reporting a more
accurate latency earlier.
https://bugzilla.gnome.org/show_bug.cgi?id=783114
It is safe to ignore it always. Tizonia notifies this error to pass
some khronos conformance tests. Problem is that gst-omx saves this
error in comp->last_error and then gst_omx_port_set_enabled early
error out which fails the pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=782800
This will check for tizilheaders.pc which adds path to omx-il
headers its cflags. Can be installed all together with the 1.2 headers
with package tizilheaders if not building from sources:
https://github.com/tizonia/tizonia-openmax-il
It is also adviced to remove libomxil-bellagio-dev package because
it installs headers /usr/include directly, ex: /usr/include/OMX_Video.h.
https://bugzilla.gnome.org/show_bug.cgi?id=782800
gst_omx_audio_enc_open will only update GstOMXAudioEnc->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
gst_omx_video_enc_open will only update GstOMXVideoEnc->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
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
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
Install libomxil-bellagio0 and make sure mesa has been built with
--enable-omx. Check there is /usr/lib/libomxil-bellagio0/libomx_mesa.so
then run omxregister-bellagio to regenerate $XDG_DATA_HOME/.omxregister
Then omxh264dec and omxmpeg2dec should load.
https://bugzilla.gnome.org/show_bug.cgi?id=782926
Does not change anything, except this will be useful for future commits.
Indeed some targets provide a .pc file where to look for the omx headers.
https://bugzilla.gnome.org/show_bug.cgi?id=782800
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
MP3 Software decoder (libmad based) but useful for testing
and to compare with other targets.
GST_OMX_CONFIG_DIR=$HOME/gst/master/gst-omx/config/bellagio/ \
gst-launch-1.0 filesrc location=mpthreetest.mp3 ! id3demux ! \
mpegaudioparse ! omxmp3dec ! audioconvert ! pulsesink
Didn't add 'local' in core-name path compared to other components
in that same gstomx.conf file because OMX.st.audio_decoder.mp3.mad
comes with the Ubuntu package 'libomxil-bellagio0-components-mad'.
All other components listed in this gstomx.conf for Bellagio, are
not provided by any Ubuntu packages. It could explain the 'local',
i.e. requiring to build them from source.
dpkg -L libomxil-bellagio0
/usr/lib/libomxil-bellagio.so.0
https://bugzilla.gnome.org/show_bug.cgi?id=781786
Signed-off-by: Gurkirpal Singh <gurkirpal204@gmail.com>
Signed-off-by: Julien Isorce <jisorce@oblong.com>
