Instead of going through the list of known muxers go ahead and
instantiate the muxer specified as 'preset name' as this specifies
the exact element factory name to use.
Currently max-errors gets set during init to default or via property.
However, if a decoder element calls gst_audio_decoder_reset with 'full'
argument set to TRUE, it would result in all the fields of context being
zeroed with memset. This effectively results in max-errors getting a
value of 0 overriding the default or user requested value set during
init.
This would result in calls to GST_AUDIO_DECODER_ERROR which track error
counts and allow max-errors, to be ineffective.
To fix this move max-errors out of GstAudioDecoderContext, as changes to
context should not affect this. The error_count is anyways also in
GstAudioDecoderPrivate and not in context.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/946>
The XV_COLORSPACE attribute exists on some Xv adapters, with the same
semantics as the XV_ITURBT_709 attribute that was already supported.
A value of 0 is bt601, and 1 is for bt709 colorspace.
Fixes color shifting issues displaying bt709 content on some Xv
adapters.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/941>
When that property is left to its default, the width and height
property considers frames from input pads with width or height <= 0
should be left unscaled in that dimension.
Setting this property to FALSE changes that behaviour to < 0, as when
animating these properties, 0 should be a valid end value (eg. shrinking
an input stream until it disappears).
The default value of the width and height properties is set to -1, so that
the default behaviour stays consistent whether that new property is set
or not.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/923>
.. and make use of that API in videoaggregator.
When setting certain properties, such as cropping or the scaled
size of pads, a new converter is created by videoaggregator.
Before that patch, this implied spawning new threads, potentially
at each aggregate cycle when interpolating pad properties. This
is obviously wasteful, and re-using a task pool removes that
overhead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/896>
Take `GST_OBJECT_LOCK` when writing `vagg->info`, so that reading in
subclasses is protected against races, as documented in the struct.
/*< public >*/
/* read-only, with OBJECT_LOCK */
GstVideoInfo info;
`gst_video_aggregator_default_negotiated_src_caps` should take the
`GST_VIDEO_AGGREGATOR_LOCK` to avoid racing with
`gst_video_aggregator_reset` called by
`gst_video_aggregator_release_pad` of the last sinkpad. Otherwise it can
happen that `latency = gst_util_uint64_scale (...` gets called with a
zero framerate.
There doesn't seem to be any reason not to use the local `info` instead
of `vagg->info`, so do that.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/915>
There is a case where there are no lines in the temp cache, and
it's possible to skip straight to the request line and not generate
intermediate ones. This is really only beneficial when doing
nearest-neighbour downscaling, as other methods generally require
all input lines sequentially to generate the output. In that case,
this change has no effect and all lines are generated and cached
as before.
As a side effect however, this fixes corruption when downscaling
using nearest-neighbour, as interactions with the pass_alloc flag
and reuse of temporary lines causes the unecessarily-generated
cache lines to overwrite the final output.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/919>
The operations for the inside GstGLUploadElement->upload have race
condition. The _transform_caps() will creates this object if it does
not exist, while the _stop() and change_state() can destroy this object.
The _transform_caps() is called by the gst_base_transform_query(),
so it does not hold the stream lock. It may use the upload while the
_stop() and change_state() has already destroy that object, and then
crash.
Fix: #645
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/913>
In the case `videoaggregator` is set as allowing format conversions,
and as we convert only on the sinkpads, we should ensure that the
chosen format is usable by the subclass. This in turns implies
that the format is usable on the srcpad.
When doing conversion *any* format can be used on the sinkpads, and this
is the only way that we can avoid race conditions during renegotiations
so we can not change that fact, we just need to ensure that the chosen
intermediary format is usable, which was not actually ensured before
that patch.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/834
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/909>
Even if given GstVideoChromaSite and/or GstVideoColorimetry has unknown
value(s), assumption for an unknown value should be done by subclass or
downstream element, not a role of video decoder. And subclass might
want to output unknown value as is.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/910>
Since 23189c60f4 we started using the
useless result of `modified_caps` which, was never used since it was
introduced 7 years ago (in videomixer2). The intersection is useless and
we should just avoid doing it at all (which was always the case before)
as it can end up failing renegotiation for bad reasons.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/905>
Setting telemetry options, even to zero, causes libtheora to enable an expensive code path. For large enough videos (e.g. 1920x1080) this can increase the time to decode each frame by 30-40 ms, which can be enough to cause noticeable stutter.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/887>
GLSLstage creates the glShader using glCreateShader, but never calls
glDeleteShader if the glShader is not used anymore. This forces the GL
library to keep the compiled shader around, because it might be used in
the future. Therefore, the glShader is leaked whenever a GLSLStage is
destroyed.
Fix the leak by deleting the glShader when finishing the GLSLStage.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/886>
