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>
This because underlying driver may have constraint on
buffer size to be dependent on period size, so period
time needs to be set first.
For e.g. Xilinx ASoC driver requires
buffer size to be multiple of period size for it's DMA
operation.
alsa-utils also set period time first as seen in below commit :
9b621eeac4
Tested it on zcu106 board with HDMI based record and playback.
Also tested on Intel PC using Logitech C920 Webcam mic and ALC887-VD
Analog for playback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1040>
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>
The current manner in transform_caps() for src direction is not very correct. For example,
when the src caps is:
video/x-raw(memory:DMABuf); video/x-raw; video/x-raw(memory:GLMemory)
this function returns:
video/x-raw(memory:DMABuf); video/x-raw; video/x-raw(memory:GLMemory)
as the sink caps. This is not correct, because DMABuf feature is not even in the sink pad's
caps template. The correct answer should be:
video/x-raw(memory:GLMemory); video/x-raw
only.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1058>
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>
If there are 3 or more known atoms in a row, it's likely that this is
actually MOV/MP4 even if we don't find any other known atoms. If 5 or
more are found then this is most certainly MOV/MP4 and we can return.
Also if a moov and mdat atom is found, this is definitely a MOV/MP4 file
and can be used as such, independent of anything else following the
mdat.
Fixes typefinding of various MOV files that have no `ftyp` atom but
otherwise a valid file structure followed by some garbage.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1013>
