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.
When we are not waiting, we need to pass -1 to signal that we just want to check
that the frame was/n't rendered. Avoids waiting for frames that will never be
rendered.
https://bugzilla.gnome.org/show_bug.cgi?id=761014
When not rendering the video frame, e.g. when freeing an unreleased sync frame,
we will not receive a frame listener callback.
Reduces the amount of 'on_frame_available miss detected' messages when dropping
frames.
https://bugzilla.gnome.org/show_bug.cgi?id=761014
The frame available callback can be called after deconfiguring the amc codec.
Guard against this by setting the back pointer to NULL on close() and ignoring
any NULL data pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=761014
Instead of just ignoring that error and then calling JNI functions with NULL,
which will kill the virtual machine.
The error handling here needs some further improvements though, errors in more
places are just ignored.
Happens when doing zerocopy rendering, or when passing a wrong index to it.
Handle this properly for zerocopy rendering, fail properly for the other
cases.
https://bugzilla.gnome.org/show_bug.cgi?id=760961
Currently it was wrongly reporting min/max as being the shortest and
longest possible frame duration. This is not how latency works in
GStreamer.
Fix by reporting min latency as being the longest possible duration of
one frame. As we don't know how many buffers the stack can accumulate, we
simply assume that max latency is the same (the usual default behaviour).
_data_queue_item_free() calls gst_buffer_unref(), which
calls gst_ahc_src_buffer_free_func(), which calls
g_mutex_lock() on self->mutex and there you go... deadlock!
This commit is a part of portng android hardware camera from 0.10 implementation.
To preserve history and get diff clearly, the interesting files are moved to
deployment directory and the remaining files are removed.
Moved the java wrapper API into its own files and made use of the
gst-dvm macros. Also renamed the API to have the proper naming
convention and coding style in order to match the one in androidcamera.
This is a work in progress! "android/media/MediaCodecList" is still missing
and the actual elements have not been ported to use the new function names.
- Create GstGLVideoAllocationParams which is a GstGLAllocationParams subclass.
- Make it possible to allocate glmemory objects directly if no frills are
needed.
The video decoders tried calling gst_buffer_add_*meta() on non-writable
buffer resulting in warnings of this kind:
gstamcvideodec.c:921 (_gl_sync_render_unlocked): WARNING: amcvideodec
Failed to create the transformation meta for the gl_sync 0xabc03848
buffer 0xabb01b40 (0)
https://bugzilla.gnome.org/show_bug.cgi?id=758694
Some devices only ever keep one buffer available in the GL queue resulting in
multiple calls to release_output_buffer only causing one frame to be rendered.
If there is a queue after amcvideodec (even playsink's small one), then
multiple buffers are pushed but only a small fraction of them are actually
rendered on time. The rest will either render some number of frames ahead of
where they are meant to be or timeout waiting for a frame that's already been
rendered.
Solved by moving the release_output_buffer into the sync_meta the is pushed
downstream. When downstream renders, the custom sync implementation attempts
to release the current buffer (if not already released) and render. Once the
frame has been rendered to the screen, the next frame is released and is
hopefully available by the time the next frame is to be rendered.
This fixes a perceived frame jitter in the output.
This provides a performance and power usage improvement by removing
the texture copy from an OES texture to 2D texture.
The flow is as follows
1. Generate the output buffer with the required sync meta with the incrementing
push counter and OES GL memory
1.1 release_output_buffer (buf, render=true) and push downstream
2. Downstream waits for on the sync meta (timed wait) or drops the frame (no wait)
2.1 Timed wait for the frame number to reach the number of frame callbacks fired
2.2 Unconditionally update the image when the wait completes (success or fail).
Sets the affine transformation matrix meta on the buffer.
3. Downstream renders as usual.
At *some* point through this the on_frame_callback may or may not fire. If it
does fire, we can finish waiting early and render. Otherwise we have to
wait for a timeout to occur which may cause more buffers to be pused into the
internal GL queue which siginificantly decreases the chances of the
on_frame_callback to fire again. This is because the frame callback only occurs
when the internal GL queue changes state from empty to non-empty.
Because there is no way to reliably correlate between the number of buffers
pushed and the number of frame callbacks received, there are a number of
workarounds in place.
1. We self-increment the ready counter when it falls behind the push counter
2. Time based waits as the frame callback may not be fired for a certain frame.
3. It is assumed that the device can render at speed or performs some QoS of
the interal GL queue (which may not match the GStreamer QoS).
It holds that we call SurfaceTexture::updateTexImage for each buffer pushed
downstream however there's no guarentee that updateTexImage will result in
the exact next frame (it could skip or duplicate) so synchronization is not
guaranteed to be accurate although it seems to be close enough to be unable
to discern visually. This has not changed from before this patch. The current
requirement for synchronization is that updateTexImage is called at the point in
time when the buffers is to be rendered.
https://bugzilla.gnome.org/show_bug.cgi?id=757285
In JNI_OnLoad() we will already get the Java VM passed and could
just directly use that. gstreamer_android-1.0.c will now provide
this to us.
Reason for this is that apparently not all Android system are
providing the JNI functions to get the currently running Java VMs, so
we would fail to get. With this we will always be able to get the Java
VM on such systems.
We only need that if no Java VM is running yet, and all usual cases,
i.e. when calling GStreamer from an actual Android app, there will already
be a Java VM we can just use.
It seems like some phones come without that symbol, let's hope they come
with the other symbol but for now don't make a missing JNI_CreateJavaVM fatal.
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
