Test included.
The problem appears when aggregator drops the query while
it's being proccessed by the klass->sink_query handler.
This can happen on FLUSH_START event. If the query is still
in the queue, it can be safely dropped, but if it's already
in the klass->sink_query() handler, then sink pad has no
choice and has to wait for the proccessing to complete.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5958>
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/5956>
Use gst_data_queue_push_force() for most events so they
are immediately enqueued. Only gap events and actual buffer
data will now block when the queue is full.
This fixes a problem with non-flushing seek handling
where events following a segment-done event would block
if they precede the SEGMENT event, since only SEGMENT
events would clear the 'eos' state of the multiqueue
queue.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5954>
Don't call wait_event() at all for gap events, as basesink will
end up waiting for the time that the gap event would be rendered
out at the audio device. There's no need to render it at all,
just treat it as a handy point to resync the audio if needed,
let the ringbuffer render silence, and place the next buffer
into the ringbuffer where it belongs.
The only thing we really need to do is make sure the ringbuffer
and clock are running, and wait for preroll.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2749
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5953>
If GST_PAD_SINK is passed in this means that we're supposed to convert
from sink caps to src caps, not the other way around. In other words, if
GST_PAD_SINK is passed we're supposed to produce the possible output
caps.
Previously this was inverted. This had the effect that glcolorconvert
pretended to be able to convert *to* I420 without glDrawBuffers, which is
not possible, and pretended not to be able to convert *from* I420
without glDrawBuffers, which it always supports.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5947>
The GstMpeg2Picture system_frame_number is guint32, constant 1000 is guint32,
GstV4l2CodecMpeg2Dec *_ref_ts multiplication result is u64 .
```
u64 result = (u32)((u32)system_frame_number * (u32)1000);
```
behaves the same as
```
u64 result = (u32)(((u32)system_frame_number * (u32)1000) & 0xffffffff);
```
so in case `system_frame_number > 4294967295 / 1000`, the `result` will
wrap around. Since the `result` is really used as a cookie used to look
up V4L2 buffers related to the currently decoded frame, this wraparound
leads to visible corruption during MPEG2 decoding. At 30 FPS this occurs
after cca. 40 hours of playback .
Fix this by changing the 1000 from u32 to u64, i.e.:
```
u64 result = (u64)((u32)system_frame_number * (u64)1000ULL);
```
this way, the wraparound is prevented and the correct cookie is used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5850>
The GstVp9Picture system_frame_number is guint32, constant 1000 is guint32,
GstV4l2CodecVp9Dec v4l2_vp9_frame.*_frame_ts multiplication result is u64 .
```
u64 result = (u32)((u32)system_frame_number * (u32)1000);
```
behaves the same as
```
u64 result = (u32)(((u32)system_frame_number * (u32)1000) & 0xffffffff);
```
so in case `system_frame_number > 4294967295 / 1000`, the `result` will
wrap around. Since the `result` is really used as a cookie used to look
up V4L2 buffers related to the currently decoded frame, this wraparound
leads to visible corruption during VP9 decoding. At 30 FPS this occurs
after cca. 40 hours of playback .
Fix this by changing the 1000 from u32 to u64, i.e.:
```
u64 result = (u64)((u32)system_frame_number * (u64)1000ULL);
```
this way, the wraparound is prevented and the correct cookie is used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5850>
The GstVp8Picture system_frame_number is guint32, constant 1000 is guint32,
GstV4l2CodecVp8Dec v4l2_vp8_frame.*_frame_ts multiplication result is u64 .
```
u64 result = (u32)((u32)system_frame_number * (u32)1000);
```
behaves the same as
```
u64 result = (u32)(((u32)system_frame_number * (u32)1000) & 0xffffffff);
```
so in case `system_frame_number > 4294967295 / 1000`, the `result` will
wrap around. Since the `result` is really used as a cookie used to look
up V4L2 buffers related to the currently decoded frame, this wraparound
leads to visible corruption during VP8 decoding. At 30 FPS this occurs
after cca. 40 hours of playback .
Fix this by changing the 1000 from u32 to u64, i.e.:
```
u64 result = (u64)((u32)system_frame_number * (u64)1000ULL);
```
this way, the wraparound is prevented and the correct cookie is used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5850>
In gst_va_allocator_try, the first try is to use derive_image, if it
succeeds, we should use info from derived image to create bufferpool.
If derive fails, then try create_image and give created image info
to the pool.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5778>
When exporting a DMABuf from a VASurface the user might tell that the surface
was allocated with certain fourcc, but the returned VADRMPRIMESurfaceDescriptor
migth tell a different fourcc, as in the case or radeonsi driver, for duplicated
fourcc, such as YUY2 and YUYV.
Originally it was supposed to be a failed exportation. This patch relax this
validation by allowing different fourcc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5778>
When overlay coordinates are updated, after the initial coordinates
are set, the shader indices are applied to the wrong buffer, resulting
in the background image appearing where the overlay should.
Bind the array buffer before applying subsequent coordinate
updates.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5909>
When level value is greater than 127, it was being clamped but this clamped
value was not the one being actually used. For level values greater than 127
this resulted in an incorrect value being used. As an example, a level value
of 187, after and'ed with 0x7F, it would result in 0x3B being reported as the
level value.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5894>
This reverts a part of de92a6c7f2. Unlike `image_filter` and
`video_filter`, `viewfinder_filter` does not get linked to `src` but
`viewfinderbin_queue`. Thus the fix in the mentioned commit does not
apply for it and should be reverted.
This was not spotted earlier as only the other filters are used in
the project that uncovered the issue.
Fixes: de92a6c7f2 ("camerabin: Fix source updates with user filters")
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5842>
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/5840>
Since the AV1 specification is not explicitly mentioning about
the array size bounds, array sizes in scalability structure
should be defined as possible maximum sizes that can have.
Also, this commit removes GST_AV1_MAX_SPATIAL_LAYERS define from
public header which is API break but the define is misleading
and this patch is introducing ABI break already
ZDI-CAN-22300
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5824>
This commit corrects the mapping relationship between RGB and BGR in GST and DRM.
The previous mapping was incorrect, causing potential color mismatches in the output.
The changes are as follows:
{WL_SHM_FORMAT_RGB888, DRM_FORMAT_RGB888, GST_VIDEO_FORMAT_BGR},
{WL_SHM_FORMAT_BGR888, DRM_FORMAT_BGR888, GST_VIDEO_FORMAT_RGB},
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5792>
If the ladspa plugin is enabled explicitly or via auto-features, the
liblrdf dependency can not be disabled.
As the RDF parsing currently provides hardly any features, the possibility
to disable it fairly useful.
Fixes: #3168
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5802>
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/5787>
This avoid a build failure when compiling against OpenSSL 3.2.0. The
problem is when windows.h is included before WinSock2.h. Because
windows.h includes winsock.h[1]. Defining _WINSOCKAPI_ stops windows.h
including winsock.h.
Error:
```
[748/1041] Compiling C object ext/dtls/gstdtls.dll.p/gstdtlscertificate.c.obj
FAILED: ext/dtls/gstdtls.dll.p/gstdtlscertificate.c.obj
[...]
Windows Kits\10\include\10.0.17763.0\shared\ws2def.h(235): error C2011: 'sockaddr': 'struct' type redefinition
Windows Kits\10\include\10.0.17763.0\um\winsock.h(482): note: see declaration of 'sockaddr'
```
[1] https://stackoverflow.com/a/1372836
Closes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3167
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5783>
Clip tile rows and cols to 64 as describe in AV1 specification
to avoid writing outside array range but preserve sb_cols
and sb_rows value which are used to futher computation.
Fixes ZDI-CAN-22226 / CVE-2023-44429
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5734>
When the subclass attempts to finish without an explicit `out_buffer`,
we take a buffer from our adapter. We need to make this buffer writable
before copying the metadata.
This led to data races such as in the following pipeline, which randomly
messed up the buffer PTS:
gst-launch-1.0 -e audiotestsrc timestamp-offset=5555 num-buffers=100 \
! opusenc ! tee name=t ! queue ! opusparse ! fakesink silent=0 \
t. ! queue ! opusparse ! fakesink silent=0 -v | grep '0000, dur'
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5720>
Whenever that caps changes does not imply that a new segment will start.
Don't reset the last_ts if only the caps have changed. This fixes issues
if you have a stream without only first frame with TS=0, and have resolution
change happening. This was a regression introduced by !3059, which issue was
described in #1352. The reported issue is still fix after this change.
Fixes#1034
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5712>
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/5695>
When copying a buffer, for example with gst_buffer_make_writable(), the
new buffer might reference the same GstMemory as the src buffer,
making those memories not writable. If the src buffer gets disposed
first it should return to its buffer pool, but since some of its
memories are not writable it gets discarded and new buffer/memory gets
allocated.
Solves this by making the new buffer keep a reference to the src buffer,
that ensures that by the time the src buffer gets disposed no other
buffer are referencing its memories and it can thus return safely to its
pool.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5696>
gst_buffer_add_parent_buffer_meta() is used when a GstBuffer uses
GstMemory from another buffer that was allocated from a pool. In that
case we want to make sure the buffer returns to the pool when the memory
is writable again, otherwise a copy of the memory is created. That means
the child buffer must drop its ref to the memory first, then drop the
ref to parent buffer so it can return to the pool when it is the only
owner of the memory.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5696>
Take the case into account when user filters have been set before the
source gets updated.
Note that the further linking of the filters, if present, happens below
in the `gst_camera_bin_check_and_replace_filter()` calls.
The audio filter is still affected by the same issue but left out for
now.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5682>
Even if IDXGIOutput6 says current display colorspace is HDR,
captured texture via IDXGIOutputDuplication::AcquireNextFrame()
is converted frame by OS unless we use IDXGIOutput5::DuplicateOutput1()
with DXGI_FORMAT_R16G16B16A16_FLOAT format, in order for captured
frame to be scRGB color space. Then application should perform
tonemap operation based on reported display white level, color primaries, etc.
Since we don't have any tonemapping implementation, ignores colorimetry
reported by IDXGIOutput6.
Fixes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3128
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5679>
This commit makes sure that pads are valid for linking
after the pads has been temporarily unlocked in the linking process.
Not doing this opens up for a race condition where
pads potentially can be linked twice.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5678>
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/5674>
This is how it was documented and how it worked before the port to GstPlay.
Without this, applications expecting signals to be emitted directly
without anything running the main context will simply not receive any
signals.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5673>
The code seems to validate that the media-level fingerprint matches
the fingerprint of the previous media or of the whole session. There
is no such requirement in any RFC I found. The session-session one
is just meant to act as a fallback when there is no media-level
fingerprint.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5663>
If text width ever reached 1px, for example after resizing the output window, the overlay would stop rendering
and never return again. The 1px condition itself does not seem to make much sense here anyway.
This was a chain of events: width reached 1, so the composition was set to NULL. Then, after resizing the output window,
push_frame() was called but would not attempt to renegotiate because composition is NULL. This caused the width/height
to never be updated again, as that only happens during negotiation, so the overlay was gone for good.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5623>
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/5611>
The src caps of the libde265 is now fixed to I420, and so if the
stream is other format, such as 4:4:4 or 10 bits format, the pipeline
will crash because the dowstream element accesses the video buffer as
I420 format.
We now restrain the input caps to "main" profile, which only contains
4:2:0 8 bits stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5596>
When decoding stream using hardware V4L2 decoder element, in any of the
currently supported formats, the decoding will fail once frame number
1000000 is reached. The reported error clearly indicates a wrap-around
occured, instead of receiving decoded frame 1000000, frame 0 is received
from the hardware V4L2 decoder driver.
The problem is actually not in the driver itself, but rather in gstreamer,
which uses `struct v4l2_buffer` member `.timestamp` in a special way. The
timestamp of buffers with encoded data added to the SINK (input) queue of
the driver is copied by the driver into matching buffers with decoded data
added to the SOURCE (output) queue of the driver. In fact, the timestamp
is not a timestamp at all, but rather in this special case, only part of
it is used as an incrementing frame counter.
The `.timestamp` is of type `struct timeval`, which is defined in
`sys/time.h` [1]. Only the `tv_usec` member of this structure is used
for the incrementing frame counter. However, suseconds_t tv_usec [2]
may be limited to range [-1, 1000000]:
"
[XSI] The type suseconds_t shall be a signed integer type capable of
storing values at least in the range [-1, 1000000].
"
Therefore, once frame 1000000 is reached, a rollover occurs and decoding
fails.
Fix this by using both `struct timeval` members, `.tv_sec` and `.tv_usec`
with matching modular arithmetic, this way the failure would occur again
just short of 2^84 frames, which should be plenty.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_time.h.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html
A test case using stateless hardware h264 decoder, the WARN/ERROR output
in gstreamer log indicates a failure occurred. With this change, that
error no longer occurs and the WARN/ERROR are not present:
```
pc$ gst-launch-1.0 videotestsrc num-buffers=1001001 pattern=6 ! \
video/x-raw,width=16,height=16,format=I420 ! \
x264enc ! filesink location=/tmp/test.h264
dut$ GST_DEBUG="*:3" gst-launch-1.0 filesrc location=/tmp/test.h264 ! \
h264parse ! v4l2slh264dec ! fakesink
...
0:03:51.393677606 12111 0x370df400 WARN \
v4l2codecs-decoder gstv4l2decoder.c:1157:gst_v4l2_request_set_done:<v4l2decoder2> \
Requested frame 1000000, but driver returned frame 0.
0:03:51.394140597 12111 0x370df400 WARN \
v4l2codecs-decoder gstv4l2decoder.c:1157:gst_v4l2_request_set_done:<v4l2decoder2> \
Requested frame 1000001, but driver returned frame 1.
0:03:51.394425216 12111 0x370df400 WARN \
v4l2codecs-decoder gstv4l2decoder.c:1157:gst_v4l2_request_set_done:<v4l2decoder2> \
Requested frame 1000002, but driver returned frame 2.
0:03:51.394665211 12111 0x370df400 WARN \
v4l2codecs-decoder gstv4l2decoder.c:1157:gst_v4l2_request_set_done:<v4l2decoder2> \
Requested frame 1000003, but driver returned frame 3.
0:03:51.394785833 12111 0x370df400 WARN \
v4l2codecs-h264dec gstv4l2codech264dec.c:1059:gst_v4l2_codec_h264_dec_output_picture:<v4l2slh264dec0> \
error: Failed to decode frame 1000000
ERROR: from element /GstPipeline:pipeline0/v4l2slh264dec:v4l2slh264dec0: Failed to decode frame 1000000
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5603>
This can happen with the dummy "noopenh264" library that the freedesktop
flatpak runtime ships, and Fedora is planning on shipping as well. In
both cases the dummy implementation gets replaced with the actual
openh264 library that's downloaded directly from Cisco, but just to be
on safe side, this patch makes it careful to check the return values to
avoid crashing if the underlying library hasn't been swapped out yet.
The patch is taken from freedesktop-sdk and was originally written by
Valentin David <valentin.david@codethink.co.uk>.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5586>
ISimpleAudioVolume controls volume of corresponding audio session
and there would be only single input/output audio session
in case of share-mode, which means that it controls audio volume of the
process. Instead, use IAudioStreamVolume interface which controls
volume of the stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5579>
Other Windows applications allow window switching even when
an application window is in fullscreen mode. Also fixing
regression introduced in 15248d8b84
which makes restored window is always located at topmost
since we do not call SetWindowPos() anymore when restoring
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5578>
Ignore alpha component of source (mouse cursor texture)
when blending alpha channel, otherwise the background area of source
(which has zeros) will be written to render target. Then it will result
in black rectangle if output texture is converted to premultiplied alpha
texture
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5577>
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/5564>
The propose and decide allocation vfuncs are called directly from
basetransform and need to use the locked accessor function for
retrieving a reliable reference to the GstGLContext (if available)
Fixes spurious crashes on shutdown during pad reconfiguration
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5518>
- Don't try to make the parameters match `GHFunc`. Use a dedicated
callback for `g_hash_table_foreach`.
- Don't try to be clever with buffer memories. We're allocating a full
packet anyway, might as well memcpy and save on a lot of complexity.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5516>
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>
Setting the surface source rectangle has been omitted so far. As a side effect
surface created with padded width/height are being scaled down. Fix this using
the viewporter source rectangle configuration. This can later be enhanced
to support crop meta.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5298>
Since d3d11convert and its variant elements does not enable basetransform's
passthrough, passthrough allocation query needs to be handled
manually in order to respect downstream element's min/max buffer
requirement.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5297>
When using `gst_sdp_media_set_media_from_caps` on `application/x-rtp` caps
without `clock-rate` it wrongly reports missing payload type even if `payload`
is present in the caps.
This seems to be a copy&paste error from the error message for missing payload
type.
When using payload=10, both `clock-rate` and some other media properties are
defined by the RTP standard so I was wondering whether I could omit `clock-rate`
and was confused about the error message.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5252>
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/5223>
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/5217>
Add gst_audio_ring_buffer_set_errored() that will mark the
ringbuffer as errored only if it is currently started or paused,
so gst_audio_ringbuffer_stop() can be sure that the error
state means that the ringbuffer was started and needs stop called.
Fixes a crash with osxaudiosrc if the source element posts
an error, because the ringbuffer would not get stopped and CoreAudio
would continue trying to do callbacks.
Also, anywhere that modifies the ringbuffer state, make sure to
use atomic operations, to guarantee their visibility
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5216>
It's quite confusing to print a function callback signature for
action signals when people need to do a g_signal_by_name() invocation
in order to use this feature. Requires too much background knowledge
about how GObject works under the hood to make sense of that.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5206>
By default, macOS attempts to run lldb against a misbehaving process to handle the crash. This does not play well
with the SISEGV/SIGQUIT handler we add in gst-launch/gst-validate. The 'spinning' mechanism causes the lldb
and debugserver processes ran by macOS to misbehave, taking 100% CPU and rendering both themselves and the GStreamer
instance frozen and very hard to effectively kill. macOS's Activity Monitor is also unusable while this is happening.
This patch takes the quickest possible solution of just disabling those signal handlers entirely on macOS.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5201>
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/5114>
When switching from a raw stream to an encoded stream we need to make sure the
slot is unlinked, there is code in place for this but it wasn't triggered
because the slot being reconfigured wasn't advertised as linked beforehand.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5133>
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/5132>
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/5099>
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/4890>
The drop-frame rules are specified in “SMPTE ST 12-3:2016” and are
consistent with the traditional ones:
“
To minimize fractional time deviation from real time, the first two
super-frame numbers (00 and 01) shall be omitted from the count at the
start of each minute except minutes 00, 10, 20, 30, 40, and 50. Thus the
first eight frame numbers (0 through 7) are omitted from the count at
the start of each minute except minutes 00, 10, 20, 30, 40, and 50.
”
Where “super-frame” is a group of 4 frames for 120 FPS.
Fixes#2797
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5061>
