When reopening a v4l2 device, the v4l2object->poll will include some old fds,
which was assigned to this device before. If the pipeline opens multiple v4l2
devices, the old fd may been assigned to other v4l2 devices when reopening
devices.
This will cause the timing of the pipeline become confusing when polling devices,
leading functional abnormalities.
Therefore, when closing v4l2object, remove the old fds in poll to ensure that the
pipeline timing is normal.
Signed-off-by: Chao Guo <chao.guo@nxp.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5820>
Apparently external-oes is not supported by the plugin as texture target,
while DMABuf uploading prefers it because it's zero copy.
This patch enables DMABuf uploading and rendering by using either 2D or
rectangle texture targets.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5795>
This simplifies the way it picks the closest caps to preference and take into
consideration the framerate to avoid picking high resolution at 5fps or so.
Simply calculate a "distance" of caps A and B from the preference and put
closest first, sorting by framerate first.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5777>
The `GstFlowCombiner` is responsible for tracking the flow of each
stream and handle the overal flow return value. Without that, we
can end up with the following scenario:
- Audio+video stream
- Only the video stream is linked downstream
- The audio stream goes EOS, video doesn't yet
-> We update the Flow in the combiner with OK as all streams are not EOS
- Video goes EOS because downstream returned EOS
-> `qtdemux` returns `FLOW_OK` forever because the unlinked audio pad
has `last_flowret==FLOW_OK`
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5724>
The tags and caps were leaked for unknown streams, I'm not sure they'd be valid
in that case, but better safe than sorry.
The tags ownership is transfered when calling `gst_adaptive_demux_track_new()`
so unreffing those afterwards was a mistake.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5714>
If this property is enabled then the jitterbuffer will do the normal PTS
calculations according to the configured mode instead of making use of
the RFC7273 media clock.
The timestamp calculated from the RFC7273 media clock will only be
stored in the reference timestamp meta, if addition of that meta is enabled.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5512>
When this property is used, it is assumed that the system clock is
synced close enough to the media clock used by an RFC7273 stream.
As long as both clocks are at most a few seconds from each other this
will give the correct results and avoids having to create an actual
network clock that has to sync first.
If the system clock is actually synchronized to the media clock then
everything will behave exactly the same, otherwise the reference
timestamp meta will be correct but the buffer timestamps will be off by
the difference between the two clocks.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5512>
Do more checks for clock equality than just checking pointers. The same
NTP/PTP clock might be used as pipeline clock but a new instance, so
instead also check what clock they are synced to.
Also handling setting / resetting of the media clock and pipeline clock
correctly by resetting the media clock's state accordingly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5512>
Because we treat raw audio chunks/samples as keyframes, they were interfering
with seek time adjustment.
Became apparent when the accompanying video stream was I-frame only,
for example ProRes.
Since raw audio streams can be seeked freely, it's fine to just ignore them here,
giving priority to the real keyframes in the video stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4946>
In snapshot mode pngenc should output exactly one frame
and then return FLOW_EOS to upstream. If upstream sends
more input frames before shutting down, it should keep
returning FLOW_EOS but not output any more encoded frames.
After a flushing seek it should output frames again though.
Fixes#3069.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5546>
The default 2MB ENCODED_BUFFER_SIZE can't support some 4K video playback. We now
detect the driver reported maximum resolution and choose an appropriate
default bitstream size accordingly. For 4K video these results in around 4MB
buffer instead of 2MB.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4549>
After rendering a QML scene the qml6glsrc 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 qml6glsrc 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.
This is a port of the original fix for the qmlglsrc element.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5519>
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/5506>
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/5471>
If the v4l2videoenc receives an QUERY_ALLOCATION, it must not propose a
currently used pool, because it cannot be sure that the allocation query came
from exactly the same upstream element. The QUERY_ALLOCATION will not contain
the internal OUTPUT pool.
The upstream element (the basesrc) detects that the newly proposed pool differs
from the old pool. It deactivates the old pool and switches to the new pool.
If there was a format change, a new OUTPUT buffer pool will be allocated in
gst_v4l2_object_set_format_full() and the CAPTURE task will be stopped to switch
the format. If there hasn't been a format change,
gst_v4l2_object_set_format_full() will not be called. The old pool will be kept
and reused.
Without a format change, the processing task continues running.
This leads to the situation that the processing task is running, but the OUTPUT
buffer pool (the old pool) is deactivated. Therefore, the encoder is not able to
get buffers from the OUTPUT pool and encoding cannot continue.
This situation can be triggered by sending a RECONFIGURE event without a format
change.
Resolve this situation by ensuring that the OUTPUT buffer pool is always
activated when frames arrive at the encoder.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4235>
There is a CAPTURE pool in the same function. While the CAPTURE pool is called
cpool, using pool for the OUTPUT pool is confusing.
Using opool for the OUTPUT pool makes it more obvious, which pool is used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4235>
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/5460>
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/5458>
There is a race condition where transfer has not been submitted yet while the
request is cancelled which leads to the transfer state going back to
`DOWNLOAD_REQUEST_STATE_OPEN` and the user of the request to get signalled about
its completion (and the task actually happening after it was cancelled) leading
to assertions and misbehaviours.
To ensure that this race can't happen, we start differentiating between the
UNSENT and CANCELLED states as in the normal case, when entering `submit_request`
the state is UNSENT and at that point we need to know that it is not because
the request has been cancelled.
In practice this case lead to an assertion in
`gst_adaptive_demux2_stream_begin_download_uri` because in a previous call to
`gst_adaptive_demux2_stream_stop_default` we cancelled the previous request and
setup a new one while it had not been submitted yet and then got a `on_download_complete`
callback called from that previous cancelled request and then we tried to do
`download_request_set_uri` on a request that was still `in_use`, leading to
something like:
```
#0: 0x0000000186655ec8 g_assert (request->in_use == FALSE)assert.c:0
#1: 0x00000001127236b8 libgstadaptivedemux2.dylib`download_request_set_uri(request=0x000060000017cc00, uri="https://XXX/chunk-stream1-00002.webm", range_start=0, range_end=-1) at downloadrequest.c:361
#2: 0x000000011271cee8 libgstadaptivedemux2.dylib`gst_adaptive_demux2_stream_begin_download_uri(stream=0x00000001330f1800, uri="https://XXX/chunk-stream1-00002.webm", start=0, end=-1) at gstadaptivedemux-stream.c:1447
#3: 0x0000000112719898 libgstadaptivedemux2.dylib`gst_adaptive_demux2_stream_load_a_fragment [inlined] gst_adaptive_demux2_stream_download_fragment(stream=0x00000001330f1800) at gstadaptivedemux-stream.c:0
#4: 0x00000001127197f8 libgstadaptivedemux2.dylib`gst_adaptive_demux2_stream_load_a_fragment(stream=0x00000001330f1800) at gstadaptivedemux-stream.c:1969
#5: 0x000000011271c2a4 libgstadaptivedemux2.dylib`gst_adaptive_demux2_stream_next_download(stream=0x00000001330f1800) at gstadaptivedemux-stream.c:2112
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5435>
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/5420>
Found that osxaudiosink could not be added standalone in gst-full build
using
-Dgst-full-elements=osxaudio:osxaudiosink because element registration
was
done at the plugin level. Now src/sink elements and deviceprovider have
their
individual registration.
Copied/adapted from the alsa plugin.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5419>
scanlines->m1 = same line of the previous field
scanlines->t0 = line above of the current field
scanlines->b0 = line below of the current field
scanlines->mp = same line of the next field
Deinterlacing a field weaved frame:
When deinterlacing the top field, the next bottom field is available
(part of the same frame). but when deinterlacing the bottom field,
the next top field (part of the next frame) is not available and
scanlines->mp equals NULL.
In this case it's better to use greedy algorithm using the prevous field
(twice) rather then linear interpolation of the current field.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5331>
If we end up with GST_CLOCK_TIME_NONE as running time for an RTP packet
then this can't be used for bitrate estimation, and also not for
constructing the next RTCP SR. Both would end up with completely wrong
values, and an RTCP SR with wrong values can easily break
synchronization in receivers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5329>
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/5296>
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/5286>
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/5286>
when playing some codec such as matroska with vp9 codec,
demuxer will save information like video_mastering_display_info
and video_content_light_level in caps that decoder need,
v4l2videodecoder can use it by calling V4L2_CTRL_CLASS_COLORIMETRY
ioctl.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4403>
If decoder notify a source change event when the capture format is
changed, not the resolution changed.
then gst_v4l2_object_acquire_format will retuen false due to
unsupported format.
we need to clear the format lists in the source change flow,
and reenumerate format list
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5218>
This elements pass RTP packets along unchanged and appear as a RTP
payloader element.
This is useful, for example when using the gstreamer-rtsp-server
library, in the case where you are receiving RTP packets from a
different source and want to serve them over RTSP. Since the
gst-rtsp-server library expect the element marked as payX to be a RTP
payloader element and assumes certain properties are available.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5204>
Imported dmabuf are not being duped, so they should never be closed. Instead,
we ensure their live time by having strong reference on their original
buffer. This should fix potential flickering due to dmabuf being closed
too early.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5101>
Now that we can split GStreamer buffers over multiple v4l2 buffer, we may
endup waiting for these buffers to be processed. Avoid waiting for any of
the parts being processed. As a side effect, the pool will now try to
grow if the number of buffers is not sufficient, and will fail
otherwise.
This fixes a hang if the very first frame did not fit. In this case, the
driver will retrain that buffer until the capture is setup, but
GStreamer won't setup the capture until process() function have
returned.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5100
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5143>
The hack enforcing strictly increasing timestamps was, according to the
code comments, because librtmp was confused with backwards timestamps.
rtmp2sink is not using librtmp as rtmpsink did, so this is no longer
required.
Also changing the timestamps is causing audio glitches when streaming to
Youtube.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5212>
These 10bit formats are identical to NV12_16L32S, but 64bytes of data is being
prefixed with 16bytes data with four pixels of lower 2bits per byte. For
MT2110T, the lower two bits set so each bytes contains a column of 4 pixels,
also describe as tiled lower 2 bits. MT2110T has been chosen as a name to match
the vendor chosen name. This format is unlikely to exist for other vendors.
For MT2110R, the 2 low bits are in raster order.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3444>
When advancing the ringbuffer, store the processed CoreAudio sample
time, then interpolate the clock in the _get_delay() calls to smooth
the clock. CoreAudio's "latency" report is always a constant and
otherwise leads to the clock generating a latency-time staircase.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5140>
Set the BufferFrame size in CoreAudio so it will deliver data
in ringbuffer segment units when recording. Otherwise, CoreAudio
will provide data in whatever granularity it wants, with no
relationship to the requested latency-time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5140>
Issue was that Qt was caching multiple different shadersbased on a static
variable location. This static variable location was the same no matter
the input video format and so if an item had an input video format of
RGB and another of RGBA, they would eventually end up using the same
GL shader leading to incorrect colours.
Fix by providing different static variable locations for each of the
different shaders that will be produced.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5145>
When we fill a bitstream buffer the buffer might be too small to hold
the entire frame. Only resize to the filled size, preventing the
following assertion to happen.
gst_buffer_resize_range: assertion 'bufmax >= bufoffs + offset + size' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5100>
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2771
This EOS branch exists so that if a seek with a stop is made, qtdemux
stops accepting bytes from the sink after the entire requested playback
range is demuxed, as otherwise we could keep download content that is
not being used.
This patch fixes two flaws that were present in that EOS check:
1) A comparison was made between track time and movie time without conversion.
This made the check trigger early in files with edit lists. This patch fixes
this by converting the track PTS to movie PTS (stream time) for the check.
2) To avoid sending a EOS prematurely when the segment stop is within a GOP and
B-frames are present, the check for EOS should only be done for keyframes. I
gather this was already the intention with the existing code, but because it
used `stream->on_keyframe` instead of the local variable `keyframe` the old
code was checking if the *previous* frame was a keyframe.
It's interesting to note that these two flaws in the old code mask each other
in most cases: the track PTS will have reached the movie end PTS, but EOS would
only be sent if the previous frame was a keyframe. A simple case where they
wouldn't mask each other, reproducing the bug, is a sequence of 3 frame GOPs
with structure I-B-P.
The following validateflow tests have been added to future-proof the
fix:
* validate.test.mp4.qtdemux_ibpibp_non_frag_pull.default
* validate.test.mp4.qtdemux_ibpibp_non_frag_push.default
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5021>
We were checking if the tag list is writable, but it may actually be
shared through the same event (tee upstream or multiple consumers).
Fix a bug where multiple branches have a videoflip element checking the
taglist. The first one was changing the orientation back to rotate-0
which was resetting the other instances.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5097>
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/5049>
The libpsl subproject wasn't building successfully and CI didn't
notice because:
1. The plugin wasn't explicitly enabled
2. Even when the plugin is explicitly enabled, the dep is not required
at build time when not building a static plugin
So fix all of these issues.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5038>
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/5034>
The videoencoder base class always uses the negotiated allocator for allocating
coded buffers and ignores the negotiated buffer pool. Therefore, the
v4l2videoenc always has to copy buffers from the pool into the allocated
output buffers.
This breaks downstream elements that want to import the CAPTURE buffers of the
v4l2videoenc, since the v4l2videoenc copies the exported CAPTURE buffers and
sends the copies downstream.
Always use the CAPTURE buffer pool for acquiring CAPTURE buffers instead of
allocating the buffers in the base class.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4230>
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/4590>
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/4987>
This fixes a build error if Qt was build without accessibility support:
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:
In member function 'bool GstQuickRenderer::init(GstGLContext*, GError**)':
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:341:13:
error: 'QCoreApplication' was not declared in this scope; did you mean 'QApplication'?
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:341:31:
error: 'app' was not declared in this scope
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:341:37:
error: 'QCoreApplication' is not a class, namespace, or enumeration
[...]
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:458:5:
error: 'QEventLoop' was not declared in this scope; did you mean 'QEvent'?
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:459:9:
error: 'loop' was not declared in this scope
If accessibility is enabled, the includes for QCoreApplication and QEventLoop
are indirectly pulled via QWidget.
Add the required headers as documented in [1] and [2].
[1] https://doc.qt.io/qt-5/qcoreapplication.html
[2] https://doc.qt.io/qt-5/qeventloop.html
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4815>
Previously, we would create a new GstMemory per write operation
and then append them to the GstBuffer. This would cause a reallocation
every 16 Memories which is an issue since the png encoder will usually
do write in a pattern of 4, 8 and 8k bytes repeating until the frame
is done.
Instead allocate a single GstMemory and keep writting it into it
with a manual index. Much like the jpegenc does.
Doing some basic testing With a testsrc snow pattern at 4k and 8k
the same pipeline would take ~3.30s to encode a 4k frame and ~23s
for an 8k. At 4k 0.70s/33% is taken by memory allocations, while at
8k its ~10.5s/45%.
With this patch, at 4k the pipeline takes ~2.40s and at 8k only 9.60s
making this 28% and 58% faster accordingly on my laptop, and
allocation runtime is dropped to subsecond times.
Here's the test pipeline used, increase num-buffers in image freeze
to gather more samples.
```
gst-launch-1.0 videotestsrc num-buffers=1 pattern=snow ! imagefreeze num-buffers=1 ! \
video/x-raw,width=7680,height=4320 ! pngenc ! fakesink
```
Close#2717
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4944>
The aim of this example is to show how to make use of the accept-certificate
signal from a GTK GUI, and prompt user in case of invalid certificate.
There are two subtleties to be aware of:
1. the signal is emitted from the GStreamer streaming thread, therefore the
caller can't modify the GUI straight away, instead they must do it from the
main thread (eg. by using g_idle_add())
2. in case of a redirection, then a TLS failure, the caller won't know
about the redirection. Actually, it's possible to be notified of the
redirection by watching "message:element" and inspecting http-headers,
but even in that case, the signal will be received *after* the signal
"accept-certificate" (even though the redirection happened *before*).
This second point is tricky. It's not uncommon to have servers that redirect
http requests to https. So errors of the type "HTTP -> HTTPS -> TLS error"
happen, and if the caller doesn't care about redirection, they might prompt
users with a message such as "TLS error for URL http://...", which wouldn't make
much sense.
This example shows how to handle that right, by connecting to the signal
"message:element", inspecting the http-headers, and in case of redirection,
updating the TLS error dialog to indicate that the request was redirected.
Here are a few examples of streams that exhibit TLS failure (at the time of
this commit, of course):
* https://radiolive.sanjavier.es:8443/stream: unknown-ca
* https://am981.ddns.net:9005/stream.ogg: unknown-ca
* http://stream.diazol.hu:7092/zene.mp3: redir then bad-identity
* https://streaming.fabrik.fm/izwi/echocast/audio/index.m3u8: unknown-ca
(this one is a HLS stream)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4925>
With libsoup 2.x, it was possible to know when there was a TLS failure, as
libsoup provided the "special http status code" SOUP_STATUS_SSL_FAILED.
However these special codes were dropped with libsoup 3.x: now libsoup emits
the accept-certificate signal when there's a TLS failure.
This commit adds a signal "accept-certificate" to SoupHttpSrc, which is in fact
just about forwarding the signal from SoupMessage (which is, itself, forwarded
from GTlsConnection). Note that, in case of libsoup 2.x, the signal is never
emitted.
Fixes: #2379
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4925>
In the current implementation, we support for most pixel format left
and top padding by changing the offset in the video meta. Though, to
align driver bytesused to the offset, we recalculate the offset, which
removed the modification we did before.
Instead, save the plane size, and truncate the driver reported bytesused
to the expected size, which ensures that the offsets still match. This
should also fix issues were the buffer size ended up bigger then the
pool size due to driver introduced padding.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4920>
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/3914>
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/3914>
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/3914>
... 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/4903>
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/4875>
- Adding bayer 10,12,14,16 bits components with 16 bits storage. These
changes only adds capabilities. Capability format string is a complete
description of the frame and pixels layout. Only mapping LE bayer
formats as v4l2 only define LE bayer formats.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4852>
When doing a segment seek, the base offset in the new segment
would be increased by segment.position which is basically the
timestamp of the last packet. This does not include the duration
of the last packet though, so might be slightly shorter than the
actual duration of the clip or the requested segment.
Increase the base offset by the segment duration instead when
accumulating segments, which is more correct as it doesn't cut
off the last frame and makes the effective loop segment duration
consistent with the actual duration returned from a duration
query.
In case a segment stop was specified it's also possible that
some data was sent beyond the stop that's necessary for decoding
so the base offset increment should be based on that then and
not on the timestamp of the last buffer pushed out.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4604>
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/4739>
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/4756>
Allow a project to use gstreamer-full as a static library
and link to create a binary without dependencies.
Introduce the option 'gst-full-target-type' to
select the build type, dynamic(default) or static.
In gstreamer-full/static build configuration gstreamer (gst.c)
needs the symbol gst_init_static_plugins which is defined
in gstreamer-full.
All the tests and examples are linking with gstreamer but the
symbol gst_init_static_plugins is only defined in the gstreamer-full
library. gstreamer-full can not be built first as it needs to know what plugins
will be built.
One option would be to build all the examples and tests after
gstreamer-full as the tools.
Disable tools build in subprojects too as it will be built at the end of
build process.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4128>
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/4701>
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/4696>
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/4696>
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/4669>
In cases that encoder needs to reset format, there is race while draining.
v4l2videoenc finish() sends CMD_STOP command to driver, and desire to return
GST_FLOW_OK. But at this time, encoder CAPTURE may have dequeued the last
buffer and got eos. finish() return value changes to be GST_FLOW_EOS which
causes set format fail. So there is no need to check return value for finish()
when set format.
Also need to flush encoder after draining to make sure flush is finished.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4495>
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/4634>
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/4637>
Assigning TRUE (1) to a signed 1 bit integer will cause truncation
from 1 to -1 because the only non-zero value that can be stored is -1
due to how two's-complement works.
As this is a proper GObject let's not bother with all this and simply
use a normal gboolean instead.
../subprojects/gst-plugins-good/ext/pulse/pulsesink.c:1490:19: warning: implicit truncation from 'int' to a one-bit
wide bit-field changes value from 1 to -1 [-Wsingle-bit-bitfield-constant-conversion]
pbuf->in_commit = TRUE;
^ ~~~~
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4617>
It could indeed be used uninitialized, but only if one of the
g_return_val_if_fail() caused an early return.
../subprojects/gst-plugins-good/gst/rtpmanager/rtpjitterbuffer.c: In function ‘rtp_jitter_buffer_append_query’:
../subprojects/gst-plugins-good/gst/rtpmanager/rtpjitterbuffer.c🔢10: warning: ‘head’ may be used uninitialized
[-Wmaybe-uninitialized]
1234 | return head;
| ^~~~
../subprojects/gst-plugins-good/gst/rtpmanager/rtpjitterbuffer.c:1232:12: note: ‘head’ was declared here
1232 | gboolean head;
| ^~~~
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4616>
Upon creating a window, glimagesink and osxvideosink now set the policy to
NSApplicationActivationPolicyRegular, which lets us show an icon in the Dock
for convenience and appear in the top menu bar like other apps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4573>
This is no longer needed since the introduction of `gst_macos_main()` in 1.22.
Before that existed, we had a patch for GLib in Cerbero, which did work but made it
impossible to update GLib at all. The code being removed was a fail-safe in case of
running without said patch being applied. It's no longer needed, since for macOS
we just wrap our GStreamer with an NSApplication using `gst_macos_main()`.
Warnings will be displayed if no NSApp/NSRunLoop is found wherever needed,
pointing the user towards using the new API.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4366>
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/4559>
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/4555>
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/4537>
jackaudiosink and jackaudiosrc have a rank and might be plugged
as part of auto-plugging inside playbin and playsink or the
autoaudiosink/autoaudiosrc elements, so we don't really want to
spew ERROR log messages in that case, which is consistent with
what alsasink and pulseaudiosink do.
This is less noticable on Linux because pulseaudiosink has a
higher and alsasink which has the same rank comes before jack
in the alphabet.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4545>
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/4536>
Atomically set and get the picture_id. This changeset only atomically gets
the picture-id when such property is queried on the element, on every other
place where it is accessed internally it is accessed directly.
This is because there is no MT scenario where we would be modifying this value
and reading it internally in parallel.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4530>
In recent versions of Chrome (M106) a change on their jitter buffer means that
they are very susceptible to PictureID discontinuities.
Then avoid at all cost resetting the PictureID. Moreover, according to
the RFCs for VP8 and VP9 payloads; the PictureID can start off at any
random value. So there is no logical problem of incrementing it here
rather than resetting it, as long as it is a different PictureID.
WebRTC's recent corruption issue:
https://bugs.chromium.org/p/webrtc/issues/detail?id=15101
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4530>
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/4535>
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/4521>
By keeping async to TRUE, a deadlock is avoided where the appsink is
filled with data after a flushing seek but before its PAUSED->PLAYING
state change finishes. If that happens, the appsink is stuck, because
its internal condition variable waits for the appsink to have more room
for data. The basesink's preroll lock is held during this, and it also
tries to acquire that lock during the state change -> deadlock.
By keeping async to TRUE, this flood of data does not happen.
Also, setting the max-buffers property to 1 is unnecessary - the test
runner will anyway detect excess memory usage if it happens.
Other property adjustments turned out to just be redundant.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4200>
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/4528>
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/4437>
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/4437>
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/4437>
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/4437>
When seek flush, gst v4l2 buffer pool flush is not atomic which will
lead double enqueue buffer (qbuf) issue, and v4l2 buffer pool qbuf is
also not atomic which will lead no free buffer found in the pool.
1. add lock for calculate enqueue number in streamon function
2. add lock for v4l2 capture end streamoff in pool flush function
3. lock the whole funciton of v4l2 buffer pool qbuf, then the buffer
pool index and qbuf operation are atomic
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4465>
when regotiation happens, v4l2src will check if it can reuse current caps,
but we need check if current caps is subset of all query caps from downstream
instead of check it with query caps one by one.
Assuming that the current caps is not the subset of first caps from query caps,
it will go to try fmt. when try fmt success, v4l2src will make pending_set_fmt
to TRUE and going to reset.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4500>
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/4498>
Fix the following use:
- upstream sends a video with a rotation tag, say 90°
- upstream switches to another video without rotation
- the second video was still rotated by videoflip
Fix this by resetting the orientation when receiving STREAM_START.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4377>
In order to provide build and provide the jack plugin with the prebuilt
binaries of gstreamer we distribute with releases, we can not depend
on an external dependency nor can we ship plugins linking to libraries
we don't provide.
We can also not provide jack ourselves, as it would likely cause a
mismatch with the jack daemon on the host.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4350>
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/4317>
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/4317>
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/4328>
Short-circuit parsing and recreating the playlist URI if
no HLS directives are going to be applied to it.
Fixes problems playing some streams (YouTube) that have
unneeded escaped characters in the URI and then complain
when GStreamer removes the escaping
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4335>
With GST_SEEK_FLAG_SNAP_AFTER present, the previous version would
adjust seek time based on the keyframe farthest away from desired_time.
This was incorrect, because we always want the *earliest* suitable keyframe
to seek to, not the last one.
With this fix, in case of the SNAP_AFTER, we now look for the closest keyframe
that can be found after desired_time. Behaviour for SNAP_BEFORE should remain
unchanged.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4183>
Assuming that V4L2 CAPTURE devices always use one buffer per JPEG image, we can
always mark JPEGs provided by a V4L2 element as parsed.
The V4L2 elements require that JPEG images sent to V4L2 OUTPUT devices must
always be parsed.
This is necessary to link a V4L2 CAPTURE device with a V4L2 OUTPUT device
without explicitly marking the stream as parsed or adding a jpegparse into the
pipeline.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4229>
There's no guarantee it will *actually* be the URI which refered to what we are
downloading. It could be a stream URI or anything else.
Instead of putting something wrong, put no (specific) referer as a better choice
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3972>
The flowcombiner and active_streams shouldn't be cleared in the
mse-bytestream variant, only in the mss-fragmented one. Otherwise the
soft reset leaves qtdemux in a state where it still believes that it has
streams, but they've been cleared. In that case, a null pointer
dereference happens and the app crashes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4199>
The abort() method of SourceBuffer in Media Source Extensions is
expected to flush the demuxer and discard the current fragment,
if any. The configuration of tracks, if any, should be preserved.
qtdemux has different behavior for flush events depending on the
context.
This patch activates the intended behaviour only for streams of the
VARIANT_MSE_BYTESTREAM type, conformant to the ISO BMFF Bytestream
specification[1]. This flush behaviour is the same as the one
already in use for adaptivedemux sources.
[1] https://www.w3.org/TR/mse-byte-stream-format-isobmff/https://bugzilla.gnome.org/show_bug.cgi?id=795424
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4101>
This patch prevents a possible race condition from taking place between the EOS event handling and rtcp send
function/thread.
The condition starts by getting the GST_EVENT_EOS event on the send_rtp_sink pad, which causes two core things
to happen -- the event gets pushed down to the send_rtp_src pad and all sessions get marked "bye" prior to
completion of the event handler. In another thread the rtp_session_on_timeout function gets called after an
expiration of gst_clock_id_wait in the rtcp_thread function. This results in a call to the
ess->callbacks.send_rtcp(), which is configured as a function pointer to gst_rtp_session_send_rtcp via the
RTPSessionCallbacks structure passed to rtp_session_set_callbacks in the gst_rtp_session_init function.
In the race condition, the call to gst_rtp_session_send_rtcp can have the all_sources_bye boolean set to true
while GST_PAD_IS_EOS(rtpsession->send_rtp_sink) evaluates to false. This is the result of gst_rtp_session_send_rtcp
running before the send_rtp_sink's GST_EVENT_EOS handler completes. The exact point at which this condition occurs
is if there's a context switch to the rtcp_thread right after the call to rtp_session_mark_all_bye in the
GET_EVENT_EOS handler, but before the handler returns.
Normally, this would not be an issue because the rtcp_thread continues to run and indirectly call
gst_rtp_session_send_rtcp. However, the call to rtp_source_reset sets the sent_bye boolean to false, which ends up
causing rtp_session_are_all_sources_bye to return false. This gets passed to gst_rtp_session_send_rtcp and the EOS
event never gets sent.
The race condition results in the EOS event never getting passed to the rtcp_src pad, which prevents the bin and
pipeline from ever completing with EOS.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3798>
Makes "start-bitrate" work without setting "connection-speed" property. Having
another property set as a requirement for this one to work is unexpected.
This commit allows to request some initial bitrate for first segment, then
go into adaptive streaming for the rest of media playback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3895>
A data offset with an offset smaller than the moof length is wrong
in smooth streaming streams. The samples will not be located and
eventually playback will error out. So compensate assuming data
is in mdat following moof.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3840>
A data offset with an offset smaller than the moof length is wrong
in smooth streaming streams.
The samples will not be located and eventually playback will
error out. So compensate assuming data is in mdat following moof.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3840>
this is an issue seen with musl based linux distros e.g. alpine [1]
musl is not going to change this since it breaks ABI/API interfaces
Newer compilers are stringent ( e.g. clang16 ) which can now detect
signature mismatches in function pointers too, existing code warned but
did not error with older clang
Fixes
gstv4l2object.c:544:23: error: incompatible function pointer types assigning to 'gint (*)(gint, ioctl_req_t, ...)' (aka 'int (*)(int, unsigned long, ...)') from 'int (int, int, ...)' [-Wincompatible-function-pointer-types]
v4l2object->ioctl = ioctl;
^ ~~~~~
[1] https://gitlab.alpinelinux.org/alpine/aports/-/issues/7580
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3950>
The av1C box is optional so dropping parsing does not break anything
fundamentally, and there seems to be no historical record how version 0
even looks like while the comments and the parsing disagreed with each
other.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3882>
When using qtdemux in a pipeline that should only work as a pure demuxer (not
for actual playback), qtdemux shouldn't emit new GstSegments to correct
the start time (jump to the future) to ensure that the user experiences no
playback delay. By doing so, it's generating the wrong segments when an append
of data from the past happens. When that happens, downstream elements such as
parsers (eg: aacparse) may clip those buffers laying before the GstSegment and
create problems on the GStreamer client app (eg: WebKit).
Getting buffers clipped out because of the wrong GstSegments started becoming
a problen when this commit was introduced:
ab6e49e9cc audioparsers: add back segment clipping to parsers that have lost it
This clipping makes test DASH shaka 35 from MVT tests[1] to fail in
WebKitGTK/WPE (at least) and can potentially cause a number of other problems
in the WebKit Media Source Extensions (MSE) code.
Note that this new behaviour of not emitting new GstSegments only makes sense
when qtdemux is being used as a pure demuxer and not as part of a regular
pipeline. This is why the variant field has been added. When equal to
VARIANT_MSE_BYTESTREAM, it will make qtdemux behave differently in push mode,
taking decisions that meet the expectations for an MSE-like processing mode.
This kind of tweaks have been done in the past for MSS streams, for instance.
That code has been refactored to use VARIANT_MSS_FRAGMENTED now, instead of
its own dedicated boolean flag.
Co-authored by: Alicia Boya García <ntrrgc@gmail.com>
...who suggested to use "variant: mse-bytestream" in the caps to identify that
mode, as proposed in her unmerged patch:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/467
[1] https://github.com/rdkcentral/mvt
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3867>
The live playlists should be updated at a defined interval. The problem is that
this interval was used *after* the playlist was finally received and processed,
which resulted in a gradual shift happening in playlist updates.
Instead store and use the time at which playlists were requested to determine
when the next one should be downloaded.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
The scanning is done in a reverse order, the proper full checks to do are
therefore:
* If the position is beyond half a "segment duration", it's in the following
segment
* If the position is within the first half of a segment, it's in that one
* If the segment is the first one and the position is within half a duration
backwards, we consider the position as being within that first segment
Also handle the case where a "partial only" segment doesn't have a reliable
duration, and therefore use the playlist target duration instead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
The implementation wouldn't work with regular HLS streams (i.e. the final
fallback).
Now that the implementation uses time to search for the starting
segment (instead of just the n-th from the end), we can specify the correct
hold_back fallback value from the RFC
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Avoid a deadlock if a downstream seeking query happens while the scheduler
thread is holding the manifest lock (for example during a seek back to live).
Instead, do a more elaborate fix where the external calls that need access to a
'manifest' access a copy that's updated during a manually triggered manifest
update callback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Rename track_dequeue_data_locked() to
gst_adaptive_demux_track_dequeue_data_locked(), since it's non-static.
Make find_stream_for_track_locked() static since it's only used in the main
gstadaptivedemux.c file.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
gst_adaptive_demux2_stream_finish_download() will already schedule another
fragment download if it can so don't fall through to the retry code that will
also try and schedule a download (triggering an assert).
Fix the logic in general to retry advancing into the live seek range once.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
When calculating the seek range for a live stream, use the same hold-back logic
as when choosing a starting segment, including low-latency segments if
enabled. Permits seeking closer to the live edge when re-synching or catching
up.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
When playing at the live edge of a live playlist, and a download fails, we don't
expect there to be a next fragment. That case is handled lower down anyway, so
don't retry infinitely on spurious http errors at the live edge.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
gst_hls_demux_stream_has_next_fragment() can be called with a NULL
current_segment if we're past the end of the current playlist. In that case,
just return FALSE instead of hitting a critical in the playlist code.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
