0xffffffff is the magic number in gst-omx meaning 'the default value
defined in OMX'. This works fine with OMX parameters which are only set
once when starting the component but not with configs which can be
changed while PLAYING.
Save the actual OMX default bitrate so we can restore it later if user
sets back 0xffffffff on the property.
Added GST_OMX_PROP_OMX_DEFAULT so we stop hardcoding magic numbers
everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=794998
Check input buffers for ROI meta and pass them to the encoder by using
zynqultrascaleplus's custom OMX extension. Also add a new
"default-roi-quality" in order to tell the encoder what quality level
should be applied to ROI by default.
https://bugzilla.gnome.org/show_bug.cgi?id=793696
The 'target-bitrate' property can be changed while PLAYING
(GST_PARAM_MUTABLE_PLAYING). Make it thread-safe to prevent concurrent
accesses between the application and streaming thread.
https://bugzilla.gnome.org/show_bug.cgi?id=793458
The Zynq UltraScale+ encoder implements a custom OMX extension to
directly import dmabuf saving the need of mapping input buffers.
This can be use with either 'v4l2src io-mode=dmabuf' or an OMX video
decoder upstream.
https://bugzilla.gnome.org/show_bug.cgi?id=792361
If the OMX component supports dynamic buffer mode and the input buffers
are properly aligned avoid copying each input frame between OMX and
GStreamer.
Tested on zynqultrascaleplus and rpi (without dynamic buffers).
https://bugzilla.gnome.org/show_bug.cgi?id=787093
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
