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>
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
