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
