WARNING: Trying to compare values of different types (str, int).
The result of this is undefined and will become a hard error
in a future Meson release.
Also remove unused libversion/soversion.
The OMX specs defines 8 headers that implementations can use to define
their custom extensions. We were checking and including 3 and ignoring
the other ones.
https://bugzilla.gnome.org/show_bug.cgi?id=792043
We are now always checking which files are present or not, even when using our
internal copy of OMX, rather than hardcoding the ones present in it.
https://bugzilla.gnome.org/show_bug.cgi?id=792043
It seems cleaner to use the proper meson tools to include this path
rather than manually tweak the build flags.
This also allows us to simplify the OMX extensions detection code. We
are now always checking which files are present, even when using our
internal copy of OMX, rather than hardcoding the ones present in it.
https://bugzilla.gnome.org/show_bug.cgi?id=792043
And uses gst_omx_args instead of add_global_arguments.
Similar to c692328521
which was only for configure.ac
Useful to get omxvp8dec with meson too:
meson . buildtmp -D with_omx_target=tizonia
https://bugzilla.gnome.org/show_bug.cgi?id=782800
The Zynq UltraScale+ uses a custom version of OMX implementing several
3rd party extensions. Make sure those are present when building this
target.
https://bugzilla.gnome.org/show_bug.cgi?id=788064
The OMX spec doesn't support HEVC but the OMX stack of the
zynqultrascaleplus adds it as a custom extension.
It uses the same API as the one of Android's OMX stack.
I used the H264 encoder code as a template.
https://bugzilla.gnome.org/show_bug.cgi?id=785434
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
