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/6280>
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/6103>
* 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/6085>
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/6046>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Do not attempt to send a streams-selected message when reassigning
an output slot in case upstream signalled that it is handling stream selection.
In this case decodebin3 doesn't keep track of stream
collections (`dbin->collection` is NULL).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5069>
Setting the input field on the empty slot prevents future linking of it and will
result in flow errors later on.
This was observed in WebKit's MediaStream source element, when it changes the
caps on one of its associated streams, from an encoded format to a raw video
format. The associated stream-id on the sticky stream-start event doesn´t
change, but the element creates a new GstStream with a different ID and sets it
on the stream-start event. Stream parsing is disabled in urisourcebin, so
decodebin3 handles the parsing. Without this patch we would end-up with unlinked
pads in decodebin3 after switching to the raw video format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5067>
Generating the source element is done when urisourcebin is doing the READY to
PAUSED state change, so it is reasonable to set the new source element to that
state.
This also allows detecting early failures with backing libraries or
hardware (checks done in NULL->READY).
Finally it makes more sense to have an element in READY when attempting to query
information from it (such as SCHEDULING queries or probing live-ness).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5058>
The current implementation copies metas without checking if the buffer
is writable.
The operation that needs to be done, replacing the input buffer and
copying the metas, is only part of that process. We create a new function
that does both.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5054>
