| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
volatile is not sufficient to provide atomic guarantees and real atomics
should be used instead. GCC 11 has started warning about using volatile
with atomic operations.
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1719
Discovered in https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/868
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2098>
|
|
|
|
|
| |
Magical 0/1 values where passed to gst_amc_codec_configure() flags
argument. It's more natural to have a boolean is gst_amc_codec_new().
|
|
|
|
|
| |
It is not needed, we can just try to get the key and ignore error.
NdkMediaFormat doesn't have that method.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Otherwise it fails to decode.
https://bugzilla.gnome.org/show_bug.cgi?id=740101
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=770158
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=763401
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=731204
|
|
|
|
|
| |
Also properly set limit/position on byte buffer, some codecs prefer to have
correct values there.
|
|
|
|
|
| |
Otherwise the base class will be confused.
See https://bugzilla.gnome.org/show_bug.cgi?id=685730
|
|
|
|
|
|
| |
They can happen sometimes as a transient problem, e.g. if there
is a problem in the stream. Only handle them as fatal if many of
them happen in a row.
|
| |
|
|
|
|
|
|
|
| |
Code flow never arrives to the break statements due to the goto's. So the
breaks are unecessary. Second part to commit a3958ae65b
https://bugzilla.gnome.org/show_bug.cgi?id=736940
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
variable when errors happen
|
|
|
|
| |
https://bugzilla.gnome.org//show_bug.cgi?id=734775
|
|
|
|
|
|
| |
flushing in error cases
... and fix a case where we released an invalid buffer index.
|
|
|
|
| |
during flushing
|
|
|
|
| |
releasing failures during flushing as an error
|
|
|
|
| |
more error/warning messages overall
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Some audio decoders (at least the MP3 decoder on MTK based devices) outputs
raw audio in batches of multiple audio frames. We need to handle that
properly, otherwise the base class will be kind of unhappy.
|
| |
|
| |
|
|
|
|
| |
And also just stop the task for FLUSHING.
|
|
|
|
|
|
|
|
| |
Flushing the decoder invalidates all buffers, so it should be done
after quiting the decoding loop. Otherwise we can jump into
"failed_release" and stop everything
https://bugzilla.gnome.org/show_bug.cgi?id=711156
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
gst_pad_template_new() does not take ownership of caps anymore and
gst_element_class_add_pad_template() does take ownership of the
pad template now.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
And make stop() faster and more robust
|
|
|
|
|
| |
And assume one decoded input frame per output buffer to fix timestamp
handling by the base class.
|
| |
|
| |
|
| |
|
|
|
|
| |
memory areas
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Some codecs don't fail the dequeueing if the codec is flushed,
causing deadlocks when shutting down the element.
|
| |
|