- Mar 19, 2024
-
-
Tim-Philipp Müller authored
-
- Mar 18, 2024
-
-
Part-of: <gstreamer/gstreamer!6390>
-
wl_shell is deprecated and has been removed from some compositors. Part-of: <!6396>
-
Even if we don't care about any global objects being removed, wayland will still error if globals are removed without a corresponding listener set up for them. e.g. wl_output hotplugging Part-of: <gstreamer/gstreamer!6396>
-
Part-of: <gstreamer/gstreamer!6396>
-
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: <gstreamer/gstreamer!6393>
-
- Mar 14, 2024
-
-
This allows distinguishing pending syncs that didn't have a DELAY_REQ sent from ones that did but used a seqnum of 0, like the very first one. Specifically, if the first one or more syncs are still pending and we send the first DELAY_REQ for a later pending sync, then the DELAY_RESP would've been wrongly associated to the very first pending sync because of the seqnum. Fixes gstreamer/gstreamer#3383 Part-of: <gstreamer/gstreamer!6368>
-
It seems that it was added by accident when copying from push-backchannel-buffer Part-of: <gstreamer/gstreamer!6366>
- Mar 13, 2024
-
-
Fixes gstreamer/gstreamer#3365 Part-of: <gstreamer/gstreamer!6360>
-
Tim-Philipp Müller authored
This reverts commit 8e923a8e. This caused regressions, see #3303. Without this commit, osxaudiosrc ! osxaudiosink won't work right, but since that hasn't really been a huge problem for years it's probably best to revert this until a proper solution can be figured out. Part-of: <gstreamer/gstreamer!6356>
-
Since commit 4d86f994, when setting an RTSP media both shared and reusable, streaming cannot be restarted after the first time all the clients disconnect. That happens because the sockets (unlike addresses) of GstRTSPStream are not cleared in gst_rtsp_stream_leave_bin, and on restart sockets and addresses are not allocated in gst_rtsp_stream_allocate_udp_sockets, and then the check in create_sender_part fails. Fix this by clearing sockets in gst_rtsp_stream_leave_bin. Fixes gstreamer/gst-rtsp-server#113 Part-of: <gstreamer/gstreamer!6347>
-
Avoids potentially ending up with the buffermemory pointing to already-freed or reused addresses. Part-of: <gstreamer/gstreamer!6349>
-
audioencoder: Avoid wrapping temporarily mapped memory with a GstBuffer and passing that to subclass Memory from gst_adapter_map() could live shorter than the GstMemory that the GstBuffer wraps around it, which in lucky cases 'just' caused a re-use of the same memory for multiple (potentially still in use!) input buffers, but could easily end up pointing to an already-freed memory. Manifested when an AudioToolbox encoder kept getting silence inserted in seemingly random circumstances, turned out to be the memory being re-used by GStreamer at the same time that the AT API was processing it... Part-of: <gstreamer/gstreamer!6349>
-
This matches autoplug in other places such as decodebin, otherwise we will pick "randomly" based on the order in which plugins are registered, which is mostly dependent on the order in which readdir() returns items. So let's make it predictable. Part-of: <gstreamer/gstreamer!6348>
-
- Mar 12, 2024
-
-
When we're doing a state change from PLAYING to NULL, first we invoke gst_rtspsrc_loop_send_cmd_and_wait (..., CMD_CLOSE, ...) during PAUSED_TO_READY which will schedule a TEARDOWN to happen async on the task thread. The task thread will call gst_rtspsrc_close(), which will send the TEARDOWN and once it's complete, it will call gst_rtspsrc_cleanup() without taking any locks, which frees src->streams. At the same time however, the state change in the app thread will progress further and in READY_TO_NULL it will call gst_rtspsrc_stop() which calls gst_rtspsrc_close() a second time, which accesses src->streams (without a lock again), which leads to simultaneous access of src->streams, and a segfault. So the state change and the cleanup are racing, but they almost always complete sequentially. Either the cleanup sets src->streams to NULL or _stop() completes first. Very rarely, _stop() can start while src->streams is being freed in a for loop. That causes the segfault. This is unlocked access is unfixable with more locking, it just leads to deadlocks. This pattern has been observed in rtspsrc a lot: state changes and cleanup in the element are unfixably racy, and that foundational issue is being addressed separately via a rewrite. The bandage fix here is to prevent gst_rtspsrc_stop() from accessing src->streams after it has already been freed by setting src->state to INVALID. Part-of: <gstreamer/gstreamer!6346>
-
- Mar 08, 2024
-
-
Part-of: <gstreamer/gstreamer!6218>
-
Fixing copy paste mistake Fixes: gstreamer/gstreamer#3321 Part-of: <gstreamer/gstreamer!6217>
-
There was a race between urisourcebin src pad handlers. One was starting the next item before the other was blocked. See gstreamer/gstreamer#3297 (comment 2288799) for details. Fix #3297 Part-of: <gstreamer/gstreamer!6214>
-
identity only needs to configure the internal seek segment if it's aggregating upstream segments into 1. If it's not, don't break other seek behaviour by refusing (for example) instant-rate change seeks. Fixes: #3363 Part-of: <gstreamer/gstreamer!6307>
-
- Mar 07, 2024
-
-
Part-of: <gstreamer/gstreamer!6294>
-
Part-of: <gstreamer/gstreamer!6294>
-
Part-of: <gstreamer/gstreamer!6294>
-
And also re-timestamp them with the current buffer's PTS. Not doing so keeps the timestamps of event packets as GST_CLOCK_TIME_NONE or the timestamp of the previous buffer, both of which are bogus. Making sure that (especially) the first packet has a valid timestamp allows putting e.g. the NTP timestamp RTP header extension on it. Part-of: <gstreamer/gstreamer!6294>
-
Leave it uninitialized, so that the downstream decoder will initialize it appropriately. Setting it to zero is wrong. Part-of: <gstreamer/gstreamer!6288>
-
Parse the speed and scale in the server's response *before* the range, so that the range start/stop are swapped (or not swapped) correctly based on the server's actual chosen values. Otherwise, the old rate from the segment is used - what the last seek asked for, but not necessarily what the server chooses. Part-of: <gstreamer/gstreamer!6287>
-
When doing direct output with no session manager, we still want to respond to queries and events from downstream, so install the handlers Part-of: <gstreamer/gstreamer!6287>
-
When transitioning back to PAUSED and rtspsrc is live, return NO_PREROLL so the pipeline knows to skip preroll here too. Part-of: <gstreamer/gstreamer!6287>
-
In the situation where playback starts from a keyframe before the target playback segment, then the first buffers will be outside the configured segment and gst_segment_to_stream_time() will return GST_CLOCK_TIME_NONE unconditionally. If drop-out-of-segment is false, the RTP buffers will not be dropped, but will be sent witout ONVIF extension timestamps and given GST_CLOCK_TIME_NONE timestamps on the receiver. Instead, use gst_segment_to_stream_time_full() to extrapolate stream time outside the segment so that such buffers still get assigned their correct timestamps on the receiver. Part-of: <gstreamer/gstreamer!6287>
-
Don't use g_return_val_if_fail() to catch the open-ended segment or empty segment cases in gst_segment_to_running_time_full() g_return_val_if_fail() is for programmer errors, and can be compiled out with a flag. Part-of: <gstreamer/gstreamer!6279>
-
Don't accidentally include the stuffing byte (if present) into the bottom field size. It should only be included in the total segment length. Fixes problems with FFmpeg not rendering the subtitles with a stuffing byte, giving a "Invalid object location!" error. Part-of: <gstreamer/gstreamer!6281>
-
- Mar 06, 2024
-
-
Cocoa version of glwindow only checks the preferred size upon window creation. glimagesink sets the size right before calling gst_gl_window_show(), which might be way after the window is created in some cases. If the size was set too late, glimagesink on macOS would remain 320x240 unless manually resized. This change makes sure to resize the existing window when _show() is called. Curiously, this has always been an issue, but went from manifesting every once in a while to being almost completely broken once old event loop workarounds were removed and gst_macos_main() was introduced. Part-of: <gstreamer/gstreamer!6280>
-
Tim-Philipp Müller authored
Part-of: <gstreamer/gstreamer!6272>
-
- Mar 04, 2024
-
-
Nirbheek Chauhan authored
It's still useful on Linux since it ensures that the tests are going to be built, since they use the same dep lookup as the plugin now. Part-of: <gstreamer/gstreamer!6198>
-
Part-of: <gstreamer/gstreamer!6198>
-
Nirbheek Chauhan authored
We have unsolvable issues on macOS because of this, and the feature was added specifically for issues that occur on Linux distros since they ship both libsoup 2.4 and 3.0. Everyone else should just pick one and use it, since you cannot mix the two in a single process anyway. Fixes gstreamer/gstreamer#1171 Part-of: <gstreamer/gstreamer!6198>
-
Nirbheek Chauhan authored
Fixes gstreamer/gstreamer#3268 Part-of: <gstreamer/gstreamer!6198>
-
Let's use gpointer for now Fixes: #3169 Part-of: <gstreamer/gstreamer!6198>
-