Reset the waiting thread counter in all places to be consistent
when sending signal for the audio ring buffer. This fix applies it to
pause, stop and release, which are states that will go into a callback
of the subclass. Having the waiting counter reset will avoid having
executing thread of the same subclass trying to take the mutex when
callong gst_audio_ring_buffer_advance.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6195>
On practice a failure happened due to a race condition, the instance
already have been freed, but it could also happen if the instance
would be null.
Instead of crashing this sanity check is a more suitable option,
since with G_DEBUG=fatal-warnings it will crash too.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6475>
This reverts commit 8e923a8e2d.
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.
(cherry picked from commit f04f86f3ee)
(cherry picked from commit 93255efece)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6405>
None of the GL allocators actually offer a generic alloc() implementation. As a
side effect, they cannot be offered as they don't work with generic video
buffer pool.
Our specialized buffer pool can be dropped by tee or alphacombine as sharing the
same buffer pool over two branch is not supported by the pool API.
Fixes#3372
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6327>
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: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6320>
This will mimic the playbin2 behaviour, which sets the "next" entry to be
NULL.
The biggest impact this has is that when going back to READY the current play
entry will be discarded (instead of being kept around for when you go back to
PAUSED/PLAYING).
Fixes#3371
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6324>
find_slot_for_stream_id() will return a slot which has the request stream-id as
active_stream *or* pending_stream (i.e. the slot on which that stream is
currently being outputted or will be outputted).
When figuring out which slot to use (if any) we want to consider stream-id
which *will* appear on a given slot which isn't outputting anything yet the same
way as if we didn't find a slot yet.
Fixes races when doing intensive state changes
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6270>
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: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6185>
The `G_DECLARE_FINAL_TYPE` macro does not need to be terminated with a
semicolon and the extra semicolon breaks building e.g. libcamera with
clang because `-Wextra-semi` is used which produces the following
error in conjunction with `-Werror`:
```
gstreamer-1.0/gst/allocators/gstdrmdumb.h:61:43: error: extra ';' outside
of a function is incompatible with C++98 [-Werror,-Wc++98-compat-extra-semi]
61 | GST, DRM_DUMB_ALLOCATOR, GstAllocator);
| ^
1 error generated.
```
Fix this by removing the extra semicolon
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6239>
When dealing with demuxers which aren't streams-aware, we need to handle the
old-school "stream replacement" dance from `parsebin` and hide that in such a
way that output pads are re-used (if compatible).
By analyzing the collection posted by parsebin, we can:
* Identify whether some output slots are no longer used (because the stream they
currently handle is not present in the collection)
* Decide if some upcoming streams could re-use the existing slot
This supports both buffering and non-buffering modes.
Fixes#1651
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6201>
When switching urisourcebin, ensure that we first unlink *all* pads from
decodebin3 before linking them again.
This is to ensure that decodebin3 completely knows that all previous pads are no
longer needed and can prepare itself to being re-used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6179>
The value is stored as an 8 bit integer, with 0 meaning that there is
not data for this extension. That means that the maximum length is 255
bytes and not 256 bytes.
On the other hand, the one-byte RTP header extensions are storing the
length as a 4 bit integer with an offset of 1 (i.e. 0 means 1 byte
extension length), so here 16 is the correct maximum length.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6180>
