New API:
- gst_gl_context_get_config()
- gst_gl_context_request_config()
A GL context configuration is a GstStructure that has some well-known
names for common values that can also be extended in platform-specific
ways if necessary.
Wrapped OpenGL contexts may be able to retrieve the GL context
configuration depending on the platform. If that information is
available, GstGLContext will attempt to create an context that matches
the shared OpenGL context config unless gst_gl_context_request_config()
has been called.
A new environment variable 'GST_GL_CONFIG' will be read to influence the
configuration chosen. The environment variable will only be used as a
fallback if gst_gl_context_request_config() has not been called.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/809>
This meta hold one buffer of the same codec data as the parent memory. This
extra frame luma will be used as the alpha values for the final combined
frame. This is notably used to support VP8/VP9 alpha as defined in WebM and
matroska specification.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1128>
These work the same way as the corresponding properties on queue and
allow to control the internal buffer size of the appsrc in a more
flexible way.
Unlike in queue the max-buffers and max-time properties are 0 (i.e.
disabled) by default for backwards compatibility reasons.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1133>
`@` references are used to reference function parameters, struct members
or enum variants _within_ the current type/function. It cannot and
should not be used to reference to types outside that.
Since C has no notion of member functions it makes little sense to
prefix these with `@`; most of the documentation here was referencing
functions on _different_ types anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1090>
If the alsasink thread starts the write loop but another thread pauses
the underlying alsa device, the sink thread will endlessly loop.
snd_pcm_writei() will return 0 if the state is SND_PCM_STATE_PAUSED
and the loop will never make any progress.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1097>
Table 1.10 – "Levels for the AAC Profile" only goes to 5 max channels
/ 7 max channel post amendmend, so I assume the number of channels
should not include LFE, otherwise there's no valid level for 5.1 resp.
7.1 (post amendmend)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/680>
Based upon valgrind finding:
Conditional jump or move depends on uninitialised value(s)
at 0x4AFF589: read_rtp_header_extensions (gstrtpbasedepayload.c:1197)
by 0x4AFF9E5: gst_rtp_base_depayload_set_headers
(gstrtpbasedepayload.c:1298)
by 0x4AFFEE0: gst_rtp_base_depayload_do_push
(gstrtpbasedepayload.c:1413)
by 0x4AFFF53: gst_rtp_base_depayload_push
(gstrtpbasedepayload.c:1448)
by 0x4AFDEBA: gst_rtp_base_depayload_handle_buffer
(gstrtpbasedepayload.c:801)
by 0x4AFE41E: gst_rtp_base_depayload_chain_list
(gstrtpbasedepayload.c:899)
by 0x48F262C: gst_pad_chain_data_unchecked (gstpad.c:4414)
by 0x48F3333: gst_pad_push_data (gstpad.c:4655)
by 0x48F3DF8: gst_pad_push_list (gstpad.c:4814)
by 0x4AFAD87: gst_rtp_base_payload_push_list
(gstrtpbasepayload.c:1978)
by 0x72B3154: gst_rtp_vp8_pay_handle_buffer (gstrtpvp8pay.c:672)
by 0x4AF7031: gst_rtp_base_payload_chain (gstrtpbasepayload.c:868)
Uninitialised value was created by a heap allocation
at 0x483C77F: malloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4B8BA78: g_malloc (gmem.c:106)
by 0x4BA3A9D: g_slice_alloc (gslice.c:1069)
by 0x488D777: _sysmem_new_block (gstallocator.c:413)
by 0x488DB28: default_alloc (gstallocator.c:512)
by 0x488D3E8: gst_allocator_alloc (gstallocator.c:310)
by 0x4AE97E3: gst_rtp_buffer_set_extension_data (gstrtpbuffer.c:856)
by 0x4AF9EC6: set_headers (gstrtpbasepayload.c:1757)
by 0x489FE4D: gst_buffer_list_foreach (gstbufferlist.c:287)
by 0x4AFA87A: gst_rtp_base_payload_prepare_push
(gstrtpbasepayload.c:1915)
by 0x4AFAD06: gst_rtp_base_payload_push_list
(gstrtpbasepayload.c:1970)
by 0x72B3154: gst_rtp_vp8_pay_handle_buffer (gstrtpvp8pay.c:672)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1075>
e.g. if we have:
video-x/raw,format=I420 ! compositor ! video/x-raw,format=BGRA
This will currently produce a warning as the alpha-ness of the chosen
'best' format (I420) will be different from the value restricted by the
downstream caps filter.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1059>
The converter might have a non-passthrough mix-matrix. The converter
can determine whether it should pass through, so let it, then remove it
if it's indeed a passthrough.
FIXME: Not converting when we need to but the config is invalid (e.g.
because the mix-matrix is not the right size) produces garbage. An
invalid config should cause a GST_FLOW_NOT_NEGOTIATED.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1070>
The users of this API need to be able to differentiate between EINTR
and ERROR. For example, in rtspsrc, gst_rtsp_conninfo_connect()
behaves differently when gst_rtsp_connection_connect_with_response_usec()
returns an ERROR or EINTR. The former is an element error while the
latter is simple a GST_ERROR since it was a user cancellation of the
connection attempt.
Due to this, rtspsrc was incorrectly emitting element errors while
going to NULL, which would or would not reach the application in
a racy manner.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1069>
While preparing a blist for pushing, some RTP header extension may
request caps change for a specific buffer in the list. When this
happens, depayloader should immediately push those buffers from the list
that precede the currently processed buffer (for which the caps change
was requested) and only then apply the new caps to the src pad.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1011>
Some header extensions may need to read information from the payloader's
sink caps. Introduce gst_rtp_header_extension_update_from_sinkcaps ()
that passes the caps to the extension, which can then use it to update
its internal state.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1011>
The way pad->priv->input_buffer reference was managed was pretty
spurious:
- it was overridden without unrefing it, which could potentially lead to
leaks.
- we were unreffing it while keeping the pointer around, which could
potentially lead to use-after-free or double-free.
As priv->input_buffer is actually no longer used outside of the
aggregate() method, remove it from pad->priv to simplify the code and
prevent the issues desribed above.
Fix a single buffer leak when shutting down the pipeline as the buffer
returned from gst_aggregator_pad_drop_buffer() was never unreffed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1061>
This code path is meant to convert the current buffer to the new format
on update. It was using priv->input_buffer as input which is either
priv->buffer or a converted version of it.
Use priv->buffer instead as priv->input_buffer may no longer be a valid
reference.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1061>
If the `render_rect` for a dispmanx display is set after calling
`window_resize` the resize defaults to the dp_width and dp_height to
determine the location of the render rectangle instead of the correct
dimensions that should be set on the window_egl.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1056>
I found a rather reproducible race in a WebKit LayoutTest when a player
was intantiated and a VP8/9 video was loaded, then torn down after
getting the video dimensions from the caps.
The crash occurs during the handling of the first frame by gstvpxdec.
The following actions happen sequentially leading to a crash.
(MT=Main Thread, ST=Streaming Thread)
MT: Sets pipeline state to NULL, which deactivates vpxdec's srcpad,
which in turn sets its FLUSHING flag.
ST: gst_vpx_dec_handle_frame() -- which is still running -- calls
gst_video_decoder_allocate_output_frame(); this in turn calls
gst_video_decoder_negotiate_unlocked() which fails because the
srcpad is FLUSHING. As a direct consequence of the negotiation
failure, a pool is NOT set.
gst_video_decoder_negotiate_unlocked() still assumes there is a
pool, crashing in a critical in gst_buffer_pool_acquire_buffer()
a couple statements later.
This patch fixes the bug by returning != GST_FLOW_OK when the
negotiation fails. If the srcpad is FLUSHING, GST_FLOW_FLUSHING is
returned, otherwise GST_FLOW_ERROR is used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1031>
GTK-Doc specifies that, by default, the caller owns returned objects, so that the caller should free them when it is done. However, in the case of this function, the returned GstAudioInfo is owned by the decoder, so this default choice is incorrect. This creates double free problems when using GStreamer Rust bindings, because they are generated using the information contained in the docs.
Fix this by correctly specifying that the caller does not own the returned object.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1032>
GTK-Doc specifies that, by default, the caller owns returned objects, so that the caller should free it when it is done. However, in the case of this function, the returned GstAudioInfo is owned by the decoder, so this default choice is incorrect. This creates double free problems when using GStreamer Rust bindings, because they are generated using the information contained in the docs.
Fix this by correctly specifying that the caller does not own the returned object.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1032>
User often want to set encoder properties on encoding profiles,
this introduces a way to easily 'preset' properties when defining the
profile. This uses GstStructure to define those properties the same
way it is done in `splitmux` for example as it makes simple to handle.
This also defines a more complex structure type where we can map a set
of properties to set depending on the muxer/encoder factory that has
been picked by EncodeBin so it is quite flexible.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1002>
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>
