First: the buffer is pushed on the encoding filesink only *after* the
checkpoints, leading to wrong ordering in expectations.
The second one is about EOS being posted on the bus *before* the
stop action is executed, leading to the action never being executed.
That action was plain useless as the default behavior of validate
scenario is to internally create a "stop" action on EOS (unless
disabled by user).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/968>
Add a way for applications to specify that the underlying file is
growing which implies that the source won't EOS when reaching the end
of the file but instead start monitoring it and start reading it again
whenever a change is detected.
Also add a validate test to check the behavior
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/937>
We've been allowing only a few known chroma-site values such as
jpeg (not co-sited), mpeg2 (horizontally co-sited) and
dv (co-sited on alternate lines). That's insufficient for
representing all possible chroma-site values. By this commit,
we can represent any combination of chroma-site flags.
But, an exception here is that any combination with
GST_VIDEO_CHROMA_SITE_NONE will be considered as invalid value.
For any combination of chroma-site flags,
gst_video_chroma_to_string() method is deprecated in order to
return newly allocated string via a new gst_video_chroma_site_to_string()
method. And for consistent API naming, gst_video_chroma_from_string()
is also deprecated. Newly written code should use
gst_video_chroma_site_from_string() instead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/927>
audiobasesrc's setcaps contains an optimization that makes it not re-
acquire the ringbuffer if the caps have not changed. However, it doesn't
check if it has successfully acquired it or not. It's possible to have
the caps set but not having ringbuffer acquired if the previous attempt
to acquire fails.
This commit replaces the caps existence check with whether the
ringbuffer is acquired or not. There's no need to check for caps
existence because 1.) it's unlikely to be NULL if the ringbuffer is
acquired, and 2.) _setcaps shouldn't be called with a NULL caps.
This should also let the element retry on acquiring ringbuffer after an
error by re-setting the element's state to READY and back to PLAYING.
Whether this behavior is correct is up for debate.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/512>
The sink_query just uses context, other_context and display to query info.
But all these objects can be changed or distroyed in state_change() func
and other places.
This patch is not very perfect. The condition race still exists in other
places in this element. All the functions directly access these objects
without protection. Most of them are executed when the data is pushing and
draw context/window have already been established, so they should not have
problems. But the sink_query and propose_allocation functions are the query
-like functions and executed in query context, which can be called in any
state of the element. So it can cause some crash issues because of destroyed
context object.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/922>
New signals are added for managing the internal list of rtp header
extension implementations read by a specific depayloader instance.
If the 'extmap-$NUM' field is present in the src caps, then an
extension implementation will be requested but is not required to be able
to negotiate correctly. An extension will be requested using the
'request-extension' signal if none could be found internally.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/748>
New signals are added for managing the internal list of rtp header
extension implementations read by a specific depayloader instance.
If the 'extmap-$NUM' field is present in the sink caps, then an
extension implementation will be requested but is not requited to be
able to negotiate correctly. An extension will be requested using the
'request-extension' signal if none could be found internally.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/748>
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/681
added a layoutSubViews, which never gets called, because it should have been
called layoutSubviews (non-capital "v"). However after fixing that, it still
doesn't work correctly, because window_width/height values are immediately
updated and then draw_cb will never trigger the resize path, because the
values are already up to date.
Update the values inside the resize path again instead, so the check for
entering the resize path is logically always correct.
This makes the layoutSubviews unnecessary, as it only updated the internal
size values prematurely, so it is deleted instead of method naming fixed.
These changes were originally done to avoid accessing UIKit objects on the
main thread, but no additional accesses are added here, only internal
private variable assignments under the same draw_lock, so there should be
no threading issues reintroduced.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/945>
A CGSize contains CGFloat values (a typedef to double or float), which means
that the values aren't equal, despite it being equal after they are cast to
int by assigning them to window_height/width private members. This leads to
excessive gst_gl_window_resize calls on each frame, at least if the CGFloat
value has a .5 decimal value, e.g. 103.5.
Fix it by storing them as CGFloat instead of gint.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/945>
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>
