MediaCodec gives us a presentation timestamp of 0 if it does not know
anything, but GStreamer gives us GST_CLOCK_TIME_NONE. Don't mix up these
two.
https://bugzilla.gnome.org/show_bug.cgi?id=780190
gstamcvideodec.c: In function 'gst_amc_video_dec_src_query':
gstamcvideodec.c:2412:55: error: 'self' undeclared (first use in this function)
if (gst_gl_handle_context_query ((GstElement *) self, query,
On the ODroid C1+ the H265 and H264 have the same name but are listed as two
different codecs. We have to handle them as the same one that supports both,
as otherwise we will register the same GType name twice which fails and we
then only have H265 support and not H264 support.
ahssrc is a new plugin that enables Gstreamer to read from the
android.hardware.Sensor Android sensors. These sensors are treated as
buffers and can be passed through and manipulated by the pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=768110
Rather than assuming something. e.g. zerocopy on iOS with GLES3 requires
the use of Luminance/Luminance Alpha formats and does not work with
Red/RG textures.
This bug was found via cppcheck static analysis.
If android.hardware.Camera.getParameters returns NULL, then object will
be NULL, and we won't allocate params. This means that the GST_DEBUG
statement referencing params->object will be invalid. Fix this by
exiting early if android.hardware.Camera.getParameters returns NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=766638
And creating one is causing assertions. Also get rid of the other CONSTRUCT
property as it's a) unneeded for default initialization and b) you're not
supposed to use constructor properties when creating element instances and the
GStreamer API doesn't provide direct ways for doing so.
https://bugzilla.gnome.org/show_bug.cgi?id=764339
In many cases, we use g_slice_new0 and then immediately overwrite the
allocated memory. This is inefficient. Since we're going to immediately
overwrite it, we might as well use plain g_slice_new.
https://bugzilla.gnome.org/show_bug.cgi?id=763998
Currently, we use AHC*_CALL macros to call many of the Camera functions.
However, we already have helper classes to call the Camera functions, so
eliminate the macros.
As a nice side-benefit, we also get improved error handling and
reporting when something goes wrong calling these functions, because a
GError gets populated, and we log a GST_ERROR when something fails. This
was harder to do using macros, as all error handling was hidden from the
caller.
https://bugzilla.gnome.org/show_bug.cgi?id=763065
In the androidmedia plugin_init, we initialize various resources on the
Android device. If anything fails during this series of initializations,
we need to deinitialize any initializations that already occurred.
However, we don't do so if we fail to register the ahcsrc element. Fix
this.
https://bugzilla.gnome.org/show_bug.cgi?id=763065
The error message is specific to only one of the failure cases and is
misleading in the others. Correct it to be more generic and cover all
the failure cases.
https://bugzilla.gnome.org/show_bug.cgi?id=763065
CPU waits are more expensive and are only required if the CPU is ever going to
access the data. GPU waits perform inter-context synchronisation and are cheaper
as they don't require CPU intervention.
