OMX.Exynos. codecs are existing on some devices like the
Galaxy S5 mini, and cause random crashes (of the device,
not the app!) and generally misbehave. That specific device
has other codecs that work with a different name, but let's
just give them marginal rank in case there are devices that
have no other codecs and these are actually the only working
ones
On some devices there are codecs that don't start with OMX., while
there are also some that do. And on some of these devices the ones
that don't start with OMX. just crash during initialization while
the others work. To make things even more complicated other devices
have codecs with the same name that work and no alternatives.
So just give a lower rank to these non-OMX codecs and hope that
there's an alternative with a higher rank.
Also stagefright gives codecs starting with OMX. a higher rank too and
considers other codecs that don't start with OMX. as software codecs.
We now fill GErrors for everything that could throw an exception, and method
calls now always return a gboolean and their value in an out-parameter to
distinguish failures from other values.
The first buffer does not contain more garbage than any other MP3 decoder
outputs and we don't really know how much we have to drop or not.
After this change the output has the same duration as with mad.
gst_pad_get_pad_template_caps() returns a reference which is unreferenced,
so creating a copy using gst_caps_copy() results in a reference leak.
Also remove the incorrect comment to avoid confusion in the future.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=734533
Check if libnativehelper is loaded in the process and if
it has these awful wrappers for JNI_CreateJavaVM and
JNI_GetCreatedJavaVMs that crash the app if you don't
create a JniInvocation instance first. If it isn't we
just fail here and don't initialize anything.
See this code for reference:
https://android.googlesource.com/platform/libnativehelper/+/master/JniInvocation.cpp
On Samsung Galaxy S4 it is impossible to have more than one
hardware decoder at the same time. If we do not release it
explicitly the GC only releases it whenever the whole application
is finished not whenever the activity is finished and thus a player
will not be able to work correctly
gst_amc_color_format_copy will copy in/out a frame resides at a
GstAmcBuffer. Lots of codes in gst_amc_video_*_fill_buffer are moved to
this new function.
Some hack logic needs also to be present in create_src|sink_caps, for
working around some broken codecs. These hacks are hidden
in color_format/video_format conversion -- the prototypes of these
functions are also changed to include more args for hack judgement.
Also in case of multi-color_formats mapped to one video_format, then
map that video_format back will not give the original color_format, which
causes gst_amc_codec_configure failed with something like
'does not support color format N'.
The new prototype involves with GstAmcCodecInfo and mime, which
ensures the converted color_format is supported by the codec.
A COLOR_FormatYCbYCr to GST_VIDEO_FORMAT_YUY2 mapping is also added, in
order to work around bugs in OMX.k3.video.decoder.avc(which incorrectly
reports supporting COLOR_FormatYCbYCr, which is actually
COLOR_FormatYUV420SemiPlanar). There are already hacks for this in
gst_amc_video_format_to_color_format, gst_amc_color_format_to_video_format
and gst_amc_color_format_info_set, but the codec will still not work(be
ignored because of "has unknown color formats") without adding this mapping.
