When the gstglimagesink is started with the option `glimagesink
render-rectangle="<0,0,1920,1080>"`, the pipeline reaches a deadlock.
The reason the deadlock occurs is that the
`gst_gl_window_set_render_rectangle` takes locks on the window, in
addition it calls `window_class->set_render_rectangle(...)` which
executes the `_on_resize` function. Since the `_on_resize` function also
takes locks on the window the deadlock is achieved.
By scheduling the adjustment of the render rectangle through an async
message for `gst_gl_window_dispmanx_set_render_rectangle`, the actual
resize happens in another context and therefore doesn't suffers from the
lock taken in `gst_gl_window_set_render_rectangle`.
This solution follows the same approach as gl/wayland. The problem was
introduced by b887db1. For the full discussion check #849.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1030>
Using RTP header extensions is currently not convenient. Users have to
handle signals from the RTP payloader and instantiate the extension
element themselves, making it impossible to use with gst-launch.
Adding a property allowing the payloader to automatically try creating
extensions. This should help simple use cases and testing using
gst-launch.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1022>
These parameters are incorrectly regarded as mutable in G-IR making them
"incompatible" with languages that are explicit about mutability like
Rust. In order to clean up the code and expected API there, update the
signatures here, right at the source (instead of overriding them in
Gir.toml and hoping for the best).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1005>
This will only make use of the framerate if the subclass is chaining up
BaseSink::set_caps(). Otherwise it will have the same behaviour as the
basesink default.
Doing so is useful if video buffers don't contain a duration to
calculate a default duration, and various video sinks already implement
a custom version of this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/986>
Elements operating in pull mode may optionally pass a buffer to
pull_range that should be filled with the data. The only element
that does that at the moment is oggdemux operating in pull mode.
tagdemux currently creates a sub-buffer whenever a buffer pulled
from upstream (filesrc, usually) needs to be trimmed. This creates
a new buffer, however, so disregards any passed-in buffer from a
downstream oggdemux.
This would cause assertion failures and playback problems for
ogg files that contain ID3 tags at the end.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/848
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/994>
This situation happens in the situation where an input stream has a framerate
exceeding the timeout latency (Ex: 1fps with a latency of 500ms) and an input
stream greater than output framerate (ex: 60fps in, 30 fps out).
The problem that would happen is that we would timeout, but then buffers from
the fast input stream would only be popped out one by one.... until a buffer
reaches the low-framerate input stream at which point they would quickly be
popped out/used. The resulting output would be "slow ... fast ... slow ... fast"
of that input fast stream.
In order to avoid this situation, whenever we detect a late buffer, check if
there's a next one and re-check with that one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/990>
Fix the following build failure with gcc 4.8 which has been added with
d268c193ad:
../gst-libs/gst/video/gstvideoaggregator.c: In function 'gst_video_aggregator_init':
../gst-libs/gst/video/gstvideoaggregator.c:2762:3: error: 'for' loop initial declarations are only allowed in C99 mode
for (gint i = 0; i < gst_caps_get_size (src_template); i++) {
^
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/974>
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>
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>
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>
.. 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>
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>
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>
In order to support the symbol g_enum_to_string in various
project using GStreamer ( gst-validate etc.), the glib minimum
version should be 2.56.0.
Remove compat code as glib requirement
is now > 2.56
Version used by Ubuntu 18.04 LTS
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/874>
We validate the header extensions length of an RTP buffer by comparing
it against the block size. Since we multiply the length in words by 4 to
get the length in bytes, a suitably large length could cause a wrapround
of the uint16, giving a lower length which erroneously passes the check
and allows the buffer to be mapped.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/864>
This is explicitly specified as valid in the RFC, where the
syntax for both parameters is:
";" "client_port" "=" port [ "-" port ]
";" "server_port" "=" port [ "-" port ]
This is useful for applications where RTCP is either not necessary
or not possible.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/846>
When user is passing the actual interlace-mode when calling
gst_video_decoder_set_interlaced_output_state() it should not be
overidden by the input interlace-mode.
Needed to fix#825 as we want to keep interlace-mode=interleaved from
parsers and have the OMX decoder producing interlace-mode=alternate.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/852>
Rename remaining `gst_video_color_transfer_{encode,decode}` functions on
the `GstVideoTransferFunction` enumeration to
`gst_video_transfer_function_{encode,decode}` permitting
gobject-introspection to turn these into associated functions and place
them under the respective `<enumeration>` block in gir XML files.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/805>
gst_pad_get_current_caps() may be wrong when there is a renegotiation in
progress for the pad and we have not yet received or selected the buffer
with different caps yet.
Fix by storing the caps through in a similar way to the existing code
for buffer/video-info selection machinery.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/813>
This allows subclasses that notice missing reference frames to request a
new sync point to allow seamless decoding again. While doing so the
subclass can also signal whether it wants a) all following input frames
until the sync point to be discarded or b) all output frames until the
sync point to be marked as corrupt.
Sending of force-keyunit events for this can be throttled by the
application via the "min-force-keyunit-interval" property.
This replaces custom behaviour for the same in various decoders, for
example openh264dec.
Based on patches by Haakon Sporsheim <haakon@pexip.com> and
Stian Selnes <stian@pexip.com>.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/730>
If the first frame(s) at the very beginning or after a flush are not a
sync point then the base class would discard them before passing them to
the subclass.
This also fixes the previously broken distance_from_sync handling: it
was never reset at sync points.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/730>
This can be used by applications to configure decoders so that corrupted
frames are directly discarded instead of being forwarded inside the
pipeline. It is a replacement for the "output-corrupt" property of the
ffmpeg decoders.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/730>
This can be used by subclasses to mark output frames as known to be
corrupted, for example if reference frames were missing. ffmpeg's
decoders can signal this.
In addition this flag is propagated downstream if the input frame had it
set.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/730>
This is not actually required (anymore?). Source pad caps can be
negotiated at any time regardless of any configured (or existing) sink
pads and videoaggregator comes up with some fixated caps based on the
downstream caps.
Subclasses can override this behaviour as needed by overriding
update_src_caps().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/793>
`gst_gl_memory_read_pixels` reads pixels from `GLMemory` into the
pointer, effectively writing to it. This is opposite from
`gst_gl_memory_texsubimage` which reads texture data from `read_pointer`
into `GLMemory`.
Both cases are clarified by changing `read_pointer` to `write_pointer`,
and explaining what `gst_gl_memory_texsubimage` does in addition to
referring back to `gst_gl_memory_read_pixels`.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/806>
These then don't require going through the generic code path via AYUV64
first but can be converted directly.
This speeds up processing of
videotestsrc ! v210 ! videoconvert ! other_format ! fakesink
by a factor of 1.55 for I420/YV12 and 1.40 for the other destination
formats and reduces memory pressure considerably.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/775>
The type is called GstVideoTransferFunction so the function names should
match, otherwise gobject-introspection is keeping the functions as
global functions instead of methods on the type.
The same mistake was also made in lots of other APIs over the years, but
here we can at least fix it for 1.18 still.
Thanks to Marijn Suijten for noticing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/807>
For audio we copy metas that have no tags at all, or that only have the
"audio" and/or "audio-channels" tag. Audio codecs don't change the
audio aspect of the stream and in almost all cases don't change the
number of channels. They might however change the sample rate (e.g.
Opus). Subclasses that change the number of channels will have to
override ::transform_meta() accordingly.
For video we copy metas that have no tags at all, or that only have the
"video" and/or "video-size" and/or "video-orientation" tag. Video codecs
don't change the "video" aspect of the stream and in almost all cases
don't change the resolution or orientation. Subclasses that rescale or
change the orientation will have to override ::transform_meta()
accordingly.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/576#note_610581
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/801>
