After rendering a QML scene the qmlglsrc element copies the contents of
the scene to a GStreamer buffer. This happens on the Qt render thread.
Then it attaches a sync point to the destination buffer. This sync point
must be awaited by other threads which use the buffer later on. The
current implementation relies on the downstream elements to wait for the
sync point. However, there are situation where this does not work. The
GstBaseTransform e.g. copies the buffer metadata (which overwrites the
sync point without waiting for it) *before* waiting for the sync point.
This commit waits for the sync point inside the qmlglsrc element before
sending it downstream. The wait command is issued on the streaming
thread with the pipeline OpenGL context, i.e. it will synchronize with
the GStreamer OpenGL thread.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5515>
The v4l2codecs H.265 decoder uses the
GstH265SliceHdr::entry_point_offset_minus1 array so make sure that it is not
freed before decoding the frame.
Before this patch, some H.265 input would segfault in
gst_v4l2_codec_h265_dec_fill_slice_params() when executing the line:
guint32 entry_point_offset = slice_hdr->entry_point_offset_minus1[i] + 1;
Make sure that the array is not freed before using it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5503>
With one regular image file path provided (without %05d),
the element was stuck in a dead loop counting the frames:
gst_image_sequence_src_count_frames
This allows to display any image file out of the element
for a given number of buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5487>
We were already converting the pad last timestamp to running time but
not the segment position.
This segment position is used by gst_aggregator_simple_get_next_time()
to compute the waiting time when aggregating.
Those waiting times were wrong in my live pipeline using the system
clock, resulting in the aggregator to never wait at all.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5465>
While adding arbitrary tile support, a round up operation was badly
converter. This caused the Y component of the stride to be 0. This
eventually lead to a crash in glupoad preceded by the following
assertion.
gst_gl_buffer_allocation_params_new: assertion 'alloc_size > 0' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5463>
While adding arbitrary tile support, a round up operation was badly
converter. This caused the Y component of the stride to be 0. This
eventually lead to a crash in glupoad preceded by the following
assertion.
gst_gl_buffer_allocation_params_new: assertion 'alloc_size > 0' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5463>
This was causing a memory leak in cases like `gltestsrc ! gltransformation scale-x=0.5 ! glimagesink`.
Parent meta was being added in assumption that those buffers are different, which was not the case here,
creating a reference loop and never freeing the buffer.
Co-authored-by: Matthew Waters <matthew@centricular.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5453>
The counter was using a signed 8 bit integer, which was overflowing
after 127 entries. That was then passed as an unsigned 32 bit integer to
libflac, which caused it to be converted to a huge unsigned number.
That then caused an invalid memory access inside libflac.
As a bonus, signed integer overflow is undefined behaviour.
Instead, use an unsigned 8 bit integer. Once this overflows the existing
code already catches it and stops adding the cue. While FLAC__metadata_object_cuesheet_insert_track()
takes an unsigned 32 bit integer for the track number, FLAC__StreamMetadata_CueSheet_Track is
limiting it to an unsigned 8 bit integer.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2921
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5436>
The interaudiosrc might take buffers of different sizes from the audio adapter,
so keeping metas consistency would be an issue. So the sink now strips the audio
metas away and the src adds them back (for non-interleaved layouts only) when
taking buffers from the adapter.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5416>
Issue is that when amc was producing a codec-data buffer, a
GstVideoCodecFrame was being popped off the internal queue. This meant
that the codec-data was being associated with the first input frame and
the second (first encoded buffer) output buffer with the second input
frame. At the end (assuming one input produces one output which seems
to hold in my testing and how the encoder is currently implemented)
there would be an input frame missing and would be pushed without any
timing information. This would lead to e.g. muxers rejecting the buffer
without PTS and failing to mux.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5335>
Even if the segmentation feature value is not updated,
the parsed "segmentation_update_map" and "segmentation_temporal_update"
values should not be cleared as it's referenced during lower
level bitstream parsing. Also, don't use assert() in parser
unless it's clearly impossible condition.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5336>
gst_video_info_set_interlaced_format() can return an error if the
width/height causes integer overflow. Handle this case, so that we can
fail cleanly. This has been experienced while testing an in-progress
driver.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5319>
Some drivers will push an buffer flagged LAST but empty. In decoder
case, this results in an "producing too many buffer" warning, even
though the result is entirely correct. Detect this case in order to
signal EOS earlier and avoid this warning.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5319>
The timestamp offset can be negative, and it can be a bigger negative
number than the latency introduced by the rtpjitterbuffer so the overall
timeout offset can be negative.
Using the negative offset for calculating how many packets can still
arrive in time when encountering a lost packet in an equidistant stream
would then overflow and instead of considering fewer packets lost a lot
more packets are considered lost.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5318>
