It's only malformed data in APP when its length is less than 6 chars,
because it should have at least an id string. Otherwise, if the id string
is not handled, no warning is raised, only a debug message noticing it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5053>
This check fixes a critical warning that can happen when a pointer motion
happens and the video doesn't have its width/height information available.
GStreamer-Video-CRITICAL **: gst_video_center_rect: assertion 'src->h != 0' failed
#0 g_logv (log_domain=0x7ffff705e176 "GStreamer-Video", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=<optimized out>) at ../../../../Projects/jhbuild/glib/glib/gmessages.c:1422
#1 0x00007ffff7e1a81d in g_log (log_domain=<optimized out>, log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff7e77a9d "%s: assertion '%s' failed") at ../../../../Projects/jhbuild/glib/glib/gmessages.c:1460
#2 0x00007ffff7e1b749 in g_return_if_fail_warning (log_domain=<optimized out>, pretty_function=<optimized out>, expression=<optimized out>) at ../../../../Projects/jhbuild/glib/glib/gmessages.c:2930
#3 0x00007ffff701d90b in gst_video_sink_center_rect (src=..., dst=..., result=result@entry=0x7fffffffc6d0, scaling=scaling@entry=1) at ../../../../Projects/jhbuild/gstreamer/subprojects/gst-plugins-base/gst-libs/gst/video/gstvideosink.c:105
#4 0x00007fffe5652dbb in _fit_stream_to_allocated_size (result=0x7fffffffc6d0, allocation=0x7fffffffc6c0, base_widget=0x9396f0) at ../../../../Projects/jhbuild/gstreamer/subprojects/gst-plugins-good/ext/gtk/gtkgstbasewidget.c:326
#5 gtk_gst_base_widget_display_size_to_stream_size (base_widget=base_widget@entry=0x9396f0, x=1207.7109375, y=811.84765625, stream_x=stream_x@entry=0x7fffffffc720, stream_y=stream_y@entry=0x7fffffffc728) at ../../../../Projects/jhbuild/gstreamer/subprojects/gst-plugins-good/ext/gtk/gtkgstbasewidget.c:344
#6 0x00007fffe5651a4b in gst_gtk_base_sink_navigation_send_event (navigation=0x5ff990, event=0x178a730) at ../../../../Projects/jhbuild/gstreamer/subprojects/gst-plugins-good/ext/gtk/gstgtkbasesink.c:340
#7 0x00007fffe5652432 in gtk_gst_base_widget_motion_event (widget=<optimized out>, event=event@entry=0x1f14b60) at ../../../../Projects/jhbuild/gstreamer/subprojects/gst-plugins-good/ext/gtk/gtkgstbasewidget.c:404
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5051>
The videoencoder base class uses getcaps() to ask a subclass for the caps in its
sink_query_default() implementation.
Replace the custom handling of the QUERY_CAPS in the v4l2videoenc with an
implementation of getcaps() that returns the caps that are supported by the
v4l2videoenc to return these caps in the query.
This getcaps() implementation also calls the provided proxy_getcaps(), which
sends a caps query to downstream. This fixes the v4l2videoenc element to respect
limits of downstream elements in a sink query.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5036>
Given the amount of complains about artifacts when negotiating dmabuf
given incompatible drm-formats, and that there's no enough bandwidth
for a proper and quick fix in gstreamer-vaapi, this patch disables,
from decoders and postprocessor, the DMABuf caps feature.
For those who needs DMABuf can use the va elements in -bad, increasing
their ranking for autoplugging by using the environment variable
GST_PLUGIN_FEATURE_RANK=vah264dec:MAX, for example.
This can be considered a first step to the deprecation of
gstreamer-vaapi in favor of the va plugin in -bad.
Fixes: #1137
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5029>
Fix compiler warnings about not using the return value when
freeing the GString segment with g_string_free(.., FALSE):
ignoring return value of ‘g_string_free_and_steal’ declared with attribute ‘warn_unused_result’
which we get with newer GLib versions. These were all harmless.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5015>
There's no reason to release GstMemory manually at all.
If we do release GstMemory, corresponding GstBuffer will be
discarded by GstBufferPool baseclass because the size is changed
to zero.
Actual cause of heavy CPU usage in case of fixed-size pool
(i.e., decoder output buffer pool) and if we remove GstMemory from
GstBuffer is that GstBufferPool baseclass is doing busy wait in acquire_buffer()
for some reason. That needs to be investigated though, discarding
and re-alloc every GstBuffer is not ideal already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4943>
If the capture pool is already active, like when handling gaps at the
start of a stream, do not setup the decoder to wait for src_ch event.
Otherwise the decoder will endup waiting for that at the wrong moment
and exit the decoding thread unexpectedly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4996>
Fix this pipeline where the tag list is not writable:
gst-launch-1.0 videotestsrc ! taginject tags="image-orientation=rotate-90" ! videoflip video-direction=auto \
! autovideosink
GStreamer-CRITICAL **: 12:34:36.310: gst_tag_list_add: assertion 'gst_tag_list_is_writable (list)' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4990>
Refusing an incoming segment in < GST_MATROSKA_READ_STATE_DATA should only be
done if the incoming segment is not in GST_FORMAT_TIME.
In GST_FORMAT_TIME, we are just storing the values and returning, so we can
invert the order of the checks.
Fixes proper segment propagation in matroska/webm DASH use-cases
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4922>
Is a seek is done on stream-collection post, there are no selected streams
yet. Therefore none would be chosen to adjust the key-unit seek.
If no streams are selected, fallback to a default stream (i.e. one which has
track(s) with GST_STREAM_FLAG_SELECT).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4922>
When seeking is handled by the collection posting thread, there is a possibility
that some leftover data will be pushed by the stream thread.
Properly detect and reject those early segments (and buffers) by comparing it to
the main segment seqnum
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4922>
... otherwise streams with constant size samples defined with a single
`sample_size` for all samples in the `stsz` box fall in the category
`chunks_are_samples` in `qtdemux_stbl_init`, overriding the actual
sample count.
`FOURCC_soun` would set this automatically for `compression_id == 0xfffe`,
however `compression_id` is read from the Audio Sample Entry box at an offset
marked as "pre-defined" in some version of the spec and set to 0 both by
GStreamer and FFmpeg for opus streams.
Considering the stream `sampled` flag is set explicitely by other fourcc
variants, doing so for opus seems consistent.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4908>
This is a small optimization and avoids restarting the next parsing
iteration on already accepted data.
On its own it would also fix ZDI-CAN-20968 (see previous commit) but the
previous commit independently is also a valid fix for it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4898>
This will cause an integer overflow a little bit further down because we
allocate a bit more memory to allow for a NUL-terminator.
The caller should've avoided passing that much data in already as it's
not going to be a valid image and there's likely not even that much data
available.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4897>
The "Encapsulation of Opus in ISO Base Media File Format" [1] specifications,
§ 4.3.2 Opus Specific Box, indicates that data must be stored as big-endian.
In `build_opus_extension`, `gst_byte_writer_put*_le ()` variants were used,
causing audio streams conversion to Opus in mp4 to offset samples due to the
PreSkip field incorrect value (29ms early in our test cases).
[1] https://opus-codec.org/docs/opus_in_isobmff.html#4.3.2
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4891>
The framerate should only be replaced (and corrected for alternating field)
when it is parsed from the bitstream. Otherwise, the upstream framerate
from caps should be trusted and assumed correct.
Related to gst-plugins-bad!2020
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4352>
If two senders use the same multicast IP and port then new_session_pad()
may try to add a srcpad to the same stream twice.
stream->srcpad is updated but gst_element_add_pad() fails the second
time. As a result stream->srcpad points to a deleted object and
access in gst_sdp_demux_stream_free() fails with a segfault.
Just ignore the second pad. Nothing useful can be done with it anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4873>
The muxer used a fixed value of 2 channels because the TR 102 366 spec
says they're to be ignored. However, the demuxer still trusted them,
resulting in bad caps.
Make the muxer fill in the correct channel count anyway (FFmpeg already
does) and make the demuxer ignore the value.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4773>
A race condition can occur in `srtpdec` during the READY -> NULL transition:
an RTCP buffer can make its way to `gst_srtp_dec_chain` while the element is
partially stopped, resulting in the following critical warning:
> Got data flow before segment event
The problematic sequence is the following:
1. An RTCP buffer is being handled by the chain function for the
`rtcp_sinkpad`. Since, this is the first buffer, we try pushing the sticky
events to `rtcp_srcpad`.
2. At the same moment, the element is being transitioned from PAUSED to READY.
3. While checking and pushing the sticky events for `rtcp_srcpad`, we reach the
Segment event. For this, we try to get it from the "otherpad", in this case
`rtp_srcpad`. In the problematic case, `rtp_srcpad` has already been
deactivated so its sticky events have been cleared. We won't be pushing any
Segment event to `rtcp_srcpad`.
4. We return to the chain function for `rtcp_sinkpad` and try pushing the
buffer to `rtcp_srcpad` for which deactivation hasn't started yet, hence the
"Got data flow before segment event".
This commit:
- Adds a boolean return value to `gst_srtp_dec_push_early_events`: in case the
Segment event can't be retrieved, `gst_srtp_dec_chain` can return an error
instead of calling `gst_pad_push`.
- Replaces the obsolete `gst_pad_set_caps` with `gst_pad_push_event`. The
additional preconditions checked by previous function are guaranteed here
since we push a fixed Caps which was built in the same function.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4860>
glfilter will unref input buffer after _transform() call immidiately,
but gpu may still reading input buffer for rendering because gl
api is executed async. Need hold reference for input buffer by
adding parent meta to output buffer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4846>
Appsink will unref prev sample in dispose function. Which is later
when V4L2 video decoder link with appsink as V4L2 video decoder
will close V4L2 device fd during GST_STATE_CHANGE_READY_TO_NULL.
If the video buffer return to V4L2 video decoder after the decoder
closed V4L2 device fd, V4L2 can't release the video frame buffer
which allocated with MMAP mode as application can't call
VIDIOC_REQBUFS 0 to release the video frame buffer by V4L2 driver.
The memory of the video frame will leak.
Unref the gstbuffer in stop() function, so V4L2 video decoder
can received all video frame buffers and release it before close
V4L2 device fd.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4820>
The qt5 and qt6 plugins will now correctly error out if you enable the
option, and you can also now explicitly ensure that wayland, x11,
eglfs support is actually functional by enabling the options. It was
too easy to build non-functional support for these.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4776>
Without this, the plugin cannot be loaded in a devenv because the
RPATH is not added to the plugin dylib. This RPATH will be stripped on
install, which is what we want.
When deploying apps, people are supposed to use `macdeployqt` to
create an AppBundle that bundles Qt for you and sets the RPATHs
correctly to point to that bundled Qt.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4776>
Configuration of our debugging system is possible before init, and in
fact is necessary too, otherwise the settings won't apply to logging
that happens during init.
For instance, since you cannot register a log function before you call
init in python, there is no way for you to log errors during init to
whatever logging service your app uses.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4763>
Due to the alpha value being inserted with _BEFORE, we were ending up
with ARGB instead of RGBA, thus displaying completely wrong colours.
According to libpng's manual, "to add an opaque alpha channel, use filler=0xff
or 0xffff and PNG_FILLER_AFTER which will generate RGBA pixels".
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4759>
self->eos was never reset after streamsynchronizer has sent EOS
(except on explicit flush or switching back to PAUSED).
As a result, synchronization was broken if new streams were pushed later
as gst_stream_synchronizer_wait() does not wait if self->eos is set.
Fix this by reseting self->eos on STREAM_START as that means a new
stream is being sent upstream and so a new EOS will follow later on.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4755>
The `switch (n_rear)` supports up to 5 rear channels, but our channel
set only had space for 3. Size the set properly to fix this.
This didn't actually cause any memory unsafety as `PUSH_CHAN` would stop
incrementing `n_rear` if the channel set is already full.
Thanks to @alatiera for noticing this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4740>
Since c0bf793c05 ("flvmux: Set PTS based on
running time") the timestamp of the output buffer is already in running
time. So using that for 'srcpad->segment.position' does not work correctly
because gst_aggregator_simple_get_next_time() will convert it again with
gst_segment_to_running_time().
This means that the timestamp returned by
gst_aggregator_simple_get_next_time() may be incorrect. For example, if
flvmux is added to a already runinng pipeline then the timestamp is too
small and gst_aggregator_wait_and_check() returns immediately. As a result,
buffers may be muxed in the wrong order.
To fix this, use the PTS of the incoming buffer instead of the outgoing
buffer. Also add the duration as get_next_time() is supposed to return the
timestamp of the next buffer, not the current one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4734>
There are broken(?) mjpeg videos that are incorrectly detected as
interlaced. This happens because 'info.height > height' (e.g. 1088 > 1080).
In the interlaced case info.height is approximately 'height * 2' but not
exactly because height is a multiple of DCTSIZE. Make the check more
restrictive but take the rounding effect into account.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4717>
For interlaced jpeg, gst_jpeg_dec_decode_direct() is called twice, once for each
field. In this case, stride[n] is plane_stride[n] * 2 to ensure that only every
other line is written. So the loop must stop at height / num_fields.
If the frame is really interlaced then continuing beyound this, is not harmful,
because jpeg_read_raw_data() will do nothing and return 0, so am info message is
printed.
However, if the frame is not actually interlaced, just misdetected as interlaced
then there is still data available from the second half of the frame. Now
line[0][j] is set to the scratch buffer. If the scratch buffer is not allocated
(because the height is a multiple of v_samp[0] * DCTSIZE) then the result is a
segfault due to a null-pointer dereference.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4717>
When the alignment contains nothing, all its fields are 0 and always
can be satisfied. So there is no need to validate it in this case.
And there are a lot of places just setting this alignment to default
all zero value, this validation generates lots of warnings.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4704>
Add d3d11 conversion path to make gst_video_convert_sample() work
for GstD3D11Memory.
Note that just adding "d3d11download" to the exisitng code is
suboptimal from GstD3D11 point of view because:
* d3d11convert element can support crop/colorspace-conversion/scale
all at once while existing software pipeline needs intermediate steps
for the conversion
* "Process everything on GPU then download it to CPU memory" would be likely
faster than "download GPU memory to CPU then processing it on CPU"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4689>
ptpd is defaulting to the hybrid mode, and was sending invalid multicast
PTP messages in that configuration until ce96c742a88792a8d92deebaf03927e1b367f4a9.
While this commit was made in 2015 there was no release in the meantime.
Work around this by detecting this case and defaulting to the default
values for the given intervals as given by the PTP standard.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4683>
Drivers may signal end of sequence using an empty buffer and LAST buffer
set, or just an empty buffer on certain legacy implementation. When this
occured, we'd send GST_V4L2_FLOW_LAST_BUFFER were the code expected
GST_FLOW_EOS. Stop abusing GST_FLOW_EOS and port all the code to the new
GST_V4L2_FLOW_LAST_BUFFER.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4671>
when play rtsp stream with playbin3 enabled, there are some critical logs:
g_object_get_is_valid_property: object class 'GstPlayBin3' has no property named 'n-video'
g_object_get_is_valid_property: object class 'GstPlayBin3' has no property named 'n-audio'
g_object_get_is_valid_property: object class 'GstPlayBin3' has no property named 'n-text'
self->collection could be NULL when READY->PAUSED if the pipeline
is live, then it will fallback to query playbin2's property,
we can call gst_play_streams_info_create_from_collection
directly, it will check self->collection internal.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4666>
Make splitmuxsrc deal better with stream reordering by
making the largest observed PTS contiguous in the
next fragment. Previously, it selected DTS, but then
aligned that with the segment start of the next fragment,
which holds PTS values - leading to glitches in
streams that don't have PTS = DTS at the start.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4660>
When reconfigure_output_stream entry missing decoder path,
requested_selection should been update with what is really
active/selected immdiately with SELECTION_LOCK hold. So
use an optional message return from reconfigure_output_stream
and post it after release SELECTION_LOCK. This can make sure
other thread call to check_slot_reconfiguration will got
a correct requested_selection.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4656>
The index is already incremented by 3 every iteration so multiplying it
by 3 additionally on each array access is doing it twice and does not
work.
This caused invalid files to be created if there's more than one CEA608
triplet in a buffer, and out of bounds memory reads.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4645>
When transitioning from state PAUSED to READY, the sctpenc element
could previously be stuck in an endless loop trying to resend data
in case the underlying sctp stream was in the process of
resetting. usrsctp_sendv() would repeatedly return EAGAIN with the
result that 0 bytes were sent and then sctpenc would retry forever.
To bring sctpenc out of the resend loop we just need to inform the
sink pad that it is flushing, which is already done for the associated
data queue, but we also need to set the bools associated with the
sinkpads that are used as the loop criterion.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4636>
Current implementation can in some cases detect
that all data is sent but in reality it is not,
leading to a push to an unlinked pad.
This is a race between the probe used to track data sent and a
call to close.
This patch sends an EOS before starting the close procedure
and then waits for the EOS event to come through to the
src pad before commencing with tear down.
This ensures that any queued data before EOS is flushed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4633>
Invoking gst_osx_video_sink_osxwindow_destroy() can currently cause a deadlock
because showFrame() keeps trying to get the same lock as well. Moving the lock
closer to where it's actually needed seems to be enough to fix the issue for now.
Reported-by: Alexande B <abobrikovich@gmail.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4627>
This is a fix for a data race leading to:
> GLib-CRITICAL: g_hash_table_foreach:
> assertion 'version == hash_table->version' failed
Identified sequence:
* `rtp_session_on_timeout` acquires the lock on `session` and proceeds with its
processing.
* `rtp_session_process_rtcp` is called (debug log : received RTCP packet) and
attempts to acquire the lock on `session`, which is still held by
`rtp_session_on_timeout`.
* as part of an hash table iterator, `rtp_session_on_timeout` transitively
invokes `source_caps` which releases the lock on `session` so as to call
`session->callbacks.caps`.
* Since `rtp_session_process_rtcp` was waiting for the lock to be released, it
succeeds in acquiring it and proceeds with `rtp_session_process_rr` which
transitively calls `g_hash_table_insert` via `add_source`.
* After `source_caps` re-acquires the lock and gives the control flow back to
`rtp_session_on_timeout`, the hash table iterator is changed, resulting in the
assertion failure.
This commits copies `sess->ssrcs[sess->mask_idx]` and iterates on the copy so
the iterator is not affected by a concurrent change due to the lock being
released in the `source_caps` callback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4585>
On very quick start/stop, the mainloop may never be run. As a side
effect, our idle stop function is not really being ran, so we can't rely
on that to free the main loop. Simply unref the mainloop when the
thread have completely stop.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4539>
If we don't do that, clients can rely on this signal to see the final pad
topology but it won't be the real one as some of them will disappear after
emitting that signal. This can happen after injecting a different init segment.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4557>
Since c2f890ab, element properties are gathered from the parse-launch
line and passed at object construction.
This caused the following issue to happen in videoflip:
* videoflip installed a CONSTRUCT property named method, now deprecated
* videoflip now also overrides that property with a video-direction
property
GObject construction causes method to be set first at construct time,
with the user-provided value, then video-direction with the default
value.
The user-provided value was thus overridden, causing a regression.
Fix by not installing the properties as CONSTRUCT, and explicitly
implementing constructed() instead in order to ensure that we do still
call gst_video_flip_set_method() at least once during construction.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2529
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4551>
A blocking pad probe is added on new sink pads, it's usually removed after the
caps have been negotiated or the signaling state switched to stable, but if that
never happens and the pad is released we kept the pad probe active, leaving the
pad blocked, preventing clean disposal.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4533>
While testing the [implementation for insertable streams] in `webrtcsink` &
`webrtcsrc`, I encountered critical warnings, which turned out to result from
two race conditions in `rtpsession`. Both race conditions produce:
> GLib-CRITICAL: g_hash_table_foreach:
> assertion 'version == hash_table->version' failed
This commit fixes one of the race conditions observed.
In its simplest form, the test consists in 2 pipelines and a Signalling server:
* pipelines_sink: audiotestsrc ! webrtcsink
* pipelines_src: webrtcsrc ! appsrc
1. Set `pipelines_sink` to `Playing`.
2. The Signalling server delivers the `producer_id`.
3. Initialize `pipelines_src` to establish a session with `producer_id`.
4. Set `pipelines_src` to `Playing`.
5. Wait for a buffer to be received by the `appsrc`.
6. Set `pipelines_src` to `Null`.
7. Set `pipelines_sink` to `Null`.
The race condition happens in the following sequence:
* `webrtcsink` runs a task to periodically retrieve statistics from `webrtcbin`.
This transitively ends up executing `rtp_session_create_stats`.
* `pipelines_sink` is set to `Null`.
* In `Paused` to `Ready`, `gst_rtp_session_change_state()` calls
`rtp_session_reset()`.
* The assertion failure occurs when `rtp_session_reset` is called while
`rtp_session_create_stats` is executing.
This is because `rtp_session_create_stats` acquires the lock on `session` prior
to calling `g_hash_table_foreach`, but `rtp_session_reset` doesn't acquire the
lock before calling `g_hash_table_remove_all`.
Acquiring the lock in `rtp_session_reset` fixes the issue.
[implementing insertable streams support]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1176
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4532>
Unfortunately streamoff does not flush the events, and this can cause all
sort of issues. Flush events on capture queue. We also return
GST_V4L2_FLOW_RESOLUTION_CHANGE in case a resolution change was seen.
This allow skipping streamon(capture) on flush, which could lead to a
configuration miss-match, or failure if the buffers aren't of the right
size.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4525>
Let the driver detects the change and reconfigure the capture side
transparently from there. This avoid reallocation of the output buffers,
and eliminates the need to stop and restart the capture task. This is
only happening if the driver have support for this, otherwise the old
behaviour is maintained.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4525>
Stop doing capture buffer allocation based on guesses
and wait for the source change event when available.
Unlike stateless decoder, the stateful decoder is not aware of
the coded resolution, and this may lead to the wrong result
even when using TRY_FMT.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4525>
In previous implementation that job was split between handle_frame and
the processing loop and it wasn't clear if this mechanism was race
free. The capture setup would also be tried for every buffer, which was
not necessary.
This also simplify the handling of SRC_CH event, dropping the unneeded
atomic boolean.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4525>
This reverts commit f29c19be58. If this is
called for the reference context then we would run into an infinite
loop, which is not really better than an assertion.
By fixing up DTS to never be ahead of the PTS in the previous commit
this situation should be impossible to hit now.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4515>
decodebin3 will do its best to figure out whether a parsebin is required to
process the incoming stream.
The problem is that for push-based stream it could happen that the stream would
not provide any caps, resulting in nothing being linked internally.
Furthermore, there is the possibility that a stream *with* caps would not be
using a TIME segment, which is required for multiqueue to properly work.
In order to fix those two issues, we force the usage of parsebin on push-based
streams:
* When the pad is linked, if upstream can't provide any caps
* When we get a non-TIME segment
Fixes#2521
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4499>
On MacOS with homebrew, the openssl library is not
properly detected with pkg-config.
So disable the test compilation if openssl
is not properly detected along with libcrypto.
libcrypto is detected but it uses the system one
which leads to the error:
your binary is not an allowed client of /usr/lib/libcrypto.dylib for
architecture x86_64
See more details from Apple:
https://developer.apple.com/forums/thread/124782
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4483>
The addresses we get from `resolve_host_finish()` (via
`resolve_host_async()`, `resolve_host_main_cb()`, `on_resolve_host()`,
`g_resolver_lookup_by_name_finish()`) must be freed. Otherwise we leak
memory.
Leak found and confirmed fixed with GCC AddressSanitizer.
Change-Id: If32d24452d626234f01b253b77a7d6d16eac1cee
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4482>
The decoder needs to force another enumeration of the format. For
this it was clearing the v4l2object insternal list, leaving a fmtdesc
pointer pointing to freed memory. This patch clears the fmtdesc pointer
that has just been free. It also makes sure the probe function does not
use the cached formats list. The probe function will restore the current
fmtdesc pointer based on the currently configured pixelformat.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4426>
As we don't have anything smart in the fixation process, we may endup with
a format that has a lower bitdepth, even if downstream can handle higher
depth. it is notably the case when negotiating with deinterlace, which places
is non-passthrough caps before its passthrough one. This makes the generic
fixation prefer the formats natively supported by deinterlace element over
the HW 10bit format. As some HW can downscale 10bit to 8bit, this can break
10bit decoding.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4426>
The original code was:
if (!gst_structure_get (s, "srtp-key", GST_TYPE_BUFFER, &buf, NULL) || !buf) {
goto error;
} else {
stream->key = buf;
}
So use "srtp-key" if it is set so a non NULL buffer. The condition was
incorrectly inverted in ad7ffe64a6 to:
if (gst_structure_get (s, "srtp-key", GST_TYPE_BUFFER, &buf, NULL) || !buf) {
stream->key = buf;
} ...
Fix the condition so it works as originally intended and avoid accessing
'buf' uninitialised.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4423>
One race condition is the fact that the window object
can be destroyed while running some routine in the UI
thread (such as resizing). To avoid that situation we make
UI thread hold a reference on the window object while it's
running.
Other probpematic case is when the window handle is reused:
if we stop and start the pipeline very fast,
so the sink creates a new window object that is going to use
the same window handle as the previous one.
And finally the case when the pipeline is stopped immediatelly
right after starting, this one is also handled in this commit.
NOTE: a unit test that reproduces this cases have been added
in the previous commit.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4417>
g_string_free(.., FALSE) gives us ownership of the string
already, no need to duplicate that again with g_strdup(),
and doing so will leak the string returned by g_string_free()
here. Caught by compiler warnings in newer GLib versions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4380>
The previous code would only check if two packets in a row were duplicates. If
not (i.e. a packet is a duplicate of a packet received slightly before) the code
would generate completely bogus FCI because it assumes there were no duplicates
present in the array.
In order to be efficient, just store all received packets and remove the
duplicates just before the FCI is generated once the array of observations have
been sorted by seqnum.
Fixes TWCC usage with moderate to high packet duplication.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4378>
The proxy and queue are created in the gst_gl_window_wayland_egl_open()
function and will be recreated on open. This leaks both objects, the
wayland client documentation mentions that they should be destroyed
using the appropriate destroy functions.
Found during valgrind memory leak testing, these blocks were marked as
definitely lost.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4355>
Existing codes rely on modified argc value by g_option_context_parse()
but g_option_context_parse_strv() is used in case of Windows.
Count arguments after the option parsing manually.
Fixing command "gst-inspect-1.0.exe -b"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4322>
Moving from PLAYING to NULL will set the stop_streaming_threads to TRUE,
but when moving back upwards its not reset to FALSE (as only done in
uncalled init and resume callbacks).
Fix by reseting value in the prepare callback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4321>
Running element_vkcolorconver test with Vulkan validation layer this error is
raised:
Code 0 : Validation Error: [ VUID-VkMappedMemoryRange-size-01390 ] Object 0:
handle = 0x100000000010, type = VK_OBJECT_TYPE_DEVICE_MEMORY;
| MessageID = 0xdd4e6d8b
| vkFlushMappedMemoryRanges: Size in pMemRanges[0] is 0x4, which is not a
multiple of VkPhysicalDeviceLimits::nonCoherentAtomSize (0x40) and offset +
size (0x0 + 0x4 = 0x4) not equal to the memory size (0xb). The Vulkan spec
states: If size is not equal to VK_WHOLE_SIZE, size must either be a multiple of
VkPhysicalDeviceLimits::nonCoherentAtomSize, or offset plus size must equal the
size of memory
The reason of is that the image size used in the test doesn't comply hardware
restrictions. In order to avoid juggling with image size and hardware
restrictions, this patch proposes to use VK_WHOLE_SIZE macro.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4311>
Running tests with Vulkan Validation enabled show an error on vkimage tests:
Code 0 : Validation Error: [ VUID-VkImageViewCreateInfo-image-04441 ]
Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle
= 0x50000000005, type = VK_OBJECT_TYPE_IMAGE;
| MessageID = 0xb75da543
| Invalid usage flag for VkImage 0x50000000005[] used by vkCreateImageView(). In
this case, VkImage should have VK_IMAGE_USAGE_SAMPLED_BIT |
VK_IMAGE_USAGE_STORAGE_BIT | VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT |
VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT |
VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT | VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT |
VK_IMAGE_USAGE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR |
VK_IMAGE_USAGE_FRAGMENT_DENSITY_MAP_BIT_EXT |
VK_IMAGE_USAGE_VIDEO_DECODE_DST_BIT_KHR |
VK_IMAGE_USAGE_VIDEO_DECODE_DPB_BIT_KHR |
VK_IMAGE_USAGE_VIDEO_ENCODE_SRC_BIT_KHR |
VK_IMAGE_USAGE_VIDEO_ENCODE_DPB_BIT_KHR | VK_IMAGE_USAGE_SAMPLE_WEIGHT_BIT_QCOM
| VK_IMAGE_USAGE_SAMPLE_BLOCK_MATCH_BIT_QCOM set during creation.
The Vulkan spec states: image must have been created with a usage value
containing at least one of the usages defined in the valid image usage list for
image views
This patch adds VK_IMAGE_USAGE_SAMPLED_BIT to the usage bits in test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4311>
While using the validation layer with this pipeline:
gst-launch-1.0 videotestsrc num-buffers=10 ! vulkanupload ! vulkancolorconvert ! vulkansink
The validation layer throws this message:
Code 0 : Validation Error: [ VUID-VkAttachmentDescription-format-06699 ]
Object 0: handle = 0x5555562e9610, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x52b3229e |
vkCreateRenderPass: pCreateInfo->pAttachments[0] format is
VK_FORMAT_B8G8R8A8_UNORM and loadOp is VK_ATTACHMENT_LOAD_OP_LOAD, but
initialLayout is VK_IMAGE_LAYOUT_UNDEFINED.
The Vulkan spec states: If format includes a color or depth aspect and loadOp is
VK_ATTACHMENT_LOAD_OP_LOAD, then initialLayout must not be VK_IMAGE_LAYOUT_UNDEFINED
When creating the render pass the loadOp can be either
`VK_ATTACHMENT_LOAD_OP_CLEAR` or `VK_ATTACHMENT_LOAD_OP_LOAD` depending on
`enable_clear`. While `enable_clear` is FALSE by default (which means
`VK_ATTACHMENT_LOAD_OP_LOAD`). Nonetheless, its value is explicitly changed by
`vkoverlaycompositor` to FALSE too!
This behavior was introduced in merge request #2470 where
`VK_ATTACHMENT_LOAD_OP_CLEAR` was a fixed value for loadOp. Thus, the bug
consists in a missing initialization of `enable_clear` to TRUE from that merge
request.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4311>
