Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Note that androidmedia requires Android gstgl
|
|
The transform from mediacodec applies to the texture coords, but
GStreamer affine meta applies to the video geometry, which is the
opposite - so invert it to get display correct for decoders
that require transforming
|
|
It should be enabled to set autofocus properly, but
it seems to be commented out mistakenly from the first commit.
https://bugzilla.gnome.org/show_bug.cgi?id=790945
|
|
|
|
from getOutputBuffer
1. Similar to 880f3d8, don't consider not getting an output buffer as
an error during flushing. I've seen the following sometimes when
encoding:
W GStreamer+amcvideoenc: java.lang.IllegalStateException
W GStreamer+amcvideoenc: at android.media.MediaCodec.getBuffer(Native Method)
W GStreamer+amcvideoenc: at android.media.MediaCodec.getOutputBuffer(MediaCodec.java:2886)
2. For amcvideodec/enc, call _find_nearest_frame (which grabs a fresh
reference on a GstVideoCodecFrame) after we have an output buffer,
so as to not leak the reference, in case getting an output buffer
fails.
Otherwise, if we get an error grabbing the output buffer, we leak
the reference to the frame. This can cause issues with a
v4l2bufferpool feeding the encoder not being able to clean itself
up properly due to buffers still being marked as in-use.
https://bugzilla.gnome.org/show_bug.cgi?id=791258
|
|
For the camera and sensor
Fixes a couple of ClassNotFound java exceptions when initializing GStreamer
off the main thread.
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=782771
|
|
Static and dynamic plugins now have the same interface. The standard
--enable-static/--enable-shared toggle are sufficient.
|
|
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
|
|
|
|
They can describe in more detail (such as component sizes) the requested format.
|
|
Don't claim it is and let h264parse and other parsers do their job.
https://bugzilla.gnome.org/show_bug.cgi?id=774772
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=774772
|
|
Claiming that it is, can cause h264parse to skip some parsing steps and
the output stays unaligned.
https://bugzilla.gnome.org/show_bug.cgi?id=774772
|
|
|
|
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,
|
|
4315a4b54d9 forgot to change the androidmedia/videotoolbox/caopengllayer
sources as required.
|
|
|
|
This is special and handled in the decoder when doing rendering to a
surface. Printing a warning for this is just unnecessary noise
|
|
|
|
This is more consistent with how we already request the application
class loader and other application resources elsewhere.
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=776591
|
|
Otherwise it fails to decode.
https://bugzilla.gnome.org/show_bug.cgi?id=740101
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=774048
|
|
Initialization failure is handled correctly by just not registering the
ahssrc element.
https://bugzilla.gnome.org/show_bug.cgi?id=774048
|
|
Some deprecated symbols are kept for backwards compatibility
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=770158
|
|
|
|
|
|
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.
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=767302
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=767298
|
|
Makes no sense to include the system error here since errno
will likely not be set and then it says 'system error: success'
which is confusing.
https://bugzilla.gnome.org/show_bug.cgi?id=767087
|
|
In general, 'dispose' function is used for dropping all references
and 'finalize' is called for releasing instances.
https://bugzilla.gnome.org/show_bug.cgi?id=763309
|
|
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
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=766679
|
|
Otherwise the GAP event fallback negotiation will fail to produce complete
srcpad caps, and thus fail.
https://bugzilla.gnome.org/show_bug.cgi?id=766289
|
|
GstAmcSurfaceTexture is more clear and simple than GstAGSurfaceTexture.
https://bugzilla.gnome.org/show_bug.cgi?id=763099
|
|
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
|
|
It's a residue of 0.10.
https://bugzilla.gnome.org/show_bug.cgi?id=763100
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=763081
|
|
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
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=763065
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=763065
|