when pipline is
glvideomixerelement->glcolorconvertelement->gldownloadelement and
glcolorconvertelement is not passthrough, the gl bufferpool between
glvideomixerelement and glcolorconvertelement will not add gl sync meta
during allocating buffer. This will cause that glcolorconvert's inbuf
has no sync meta to wait for.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6756>
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>
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>
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>
When allocating buffers with alignment parameters specified, it
may be necessary to overallocate memory to adjust to the requested
alignment. Previously the padding length was not included in the mmaped
buffer size, leaving unmapped bytes at the end of the buffer.
This caused intermittent SEGV faults and valgrind failures when running
the wayland_threads example.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6104>
* Bump the rank of the musepack v7/v8 FFmpeg demuxers to SECONDARY
* Bump the rank of the musepack v7/v8 FFmpeg audio decoders to SECONDARY
* Demote the rank of the musepackdec element to MARGINAL
This is for two reasons:
* The musepack library is no longer maintained, whereas the FFmpeg
implementation can/will receive fixes
* The `musepackdec` implementation was a all-in-one "parsing and decoding" blob
which doesn't play nicely with decodebin3 and others
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3033
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6074>
If the allocation function get called from multiple threads at the same time,
multiple allocators may get created but only one get saved. Leading to other
allocators to be leaked. Simply create it once in the instance initialization.
Fixes: #2456
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6052>
- Support HTTP redirect codes (301,302,307,308) on response to GET.
"Location" field is extracted and used for following GET and POST.
- Notify caller a redirect took place using return value
- log source and destination url on redirect
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5222>
Converting from RGB to YUV: When comparing the info.colorimetry to
GST_VIDEO_COLORIMETRY_BT709 it does not make sense to look at the input
signal because that is of type of RGB. The plugin needs to look at the
output YUV-type and compare GST_VIDEO_COLORIMETRY_BT709 to that, because
that is the YUV-type the plugin needs to convert input-RGB into.
Converting from YUV to RGB: Comparing to the input is correct, but because
here the color encoding info BT601/BT709 is on input side of the plugin.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5998>
