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/5205>
Section 3.4 in RFC8835 states that if a WebRTC endpoint uses an HTTP
proxy to access the Internet it MUST include the "ALPN" header. This
commit adds this header.
By default the ALPN used when connecting to the TURN/TCP server via a
proxy is set to "webrtc". It can be changed by adding an alpn url
option for the http-proxy. For example:
http://user:pass@my.http.proxy.com:8080?alpn=c-webrtc
This will add the header "ALPN: c-webrtc" to the HTTP proxy CONNECT
request.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4212>
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/5190>
Adds gst_queue_array_sort for sorting and gst_queue_array_push_sorted{,struct} for pushing in a sorted order.
All three functions accept a comparison GCompareDataFunc along with optional user_data to pass to it.
In gst_queue_array_sort a small workaround was needed to correctly sort non-struct arrays. Like what _find() already
does, we need to dereference our pointers first, to make sure we can use the same comparison functions everywhere.
This is done via a small wrapper around the provided comparison function.
The array can also wrap around (tail ends up 'before' the head), in which case we have to reorder the array (similar to
what do_expand() does) to then be able to use an existing sorting function, like g_qsort_with_data().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5112>
If a depayloader aggregates multiple RTP buffers into one buffer only
the last RTP buffer was checked for header extensions. Now the
depayloader remembers all RTP packets pushed before a output buffer is
pushed and checks all RTP buffers for header extensions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4979>
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/5178>
Adding cudaipc{src,sink} element for CUDA IPC support.
Implementation note:
* For the communication between end points, Win32 named-pipe
and unix domain socket will be used on Windows and Linux respectively.
* cudaipcsink behaves as a server, and all GPU resources will be owned by
the server process and exported for other processes, then cudaipcsrc
(client) will import each exported handle.
* User can select IPC mode via "ipc-mode" property of cudaipcsink.
There are two IPC mode, one is "legacy" which uses legacy CUDA IPC
method and the other is "mmap" which uses CUDA virtual memory API
with OS's resource handle sharing method such as DuplicateHandle()
on Windows. The "mmap" mode might be better than "legacy" in terms
of stability since it relies on OS's resource management but
it would consume more GPU memory than "legacy" mode.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4510>
If glyphrun unit is changed in a single line, there could be
overlapped background area which result in drawing background
twice. Adding geometry combine so that background geometry objects
with the same color can be merged and rendered at once
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5179>
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2900
The `reports` list was being copied as a reference, therefore, copies of
a test ended up inadvertedly sharing the same list of reports. Reports
added by one instance of the test would be reflected in all instances.
This caused a race condition where, if a test was run on repeat with
gst-validate-launcher -f, very often wrong log file was shown to the
user. For instance, gst-validate-launcher would say "test failed, see
log for iteration7", but iteration7 would contain "TEST PASSED".
Worse, the runner would add the report to that incorrect log file,
mixing problems between different executions of the tests.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5177>
Latest MSYS2 MinGW provides these now, so we don't need to define them
if they're already present in the header.
The AudioClient3 GUID requires the Windows 10 SDK, so it's only
available in the latest MinGW, and the MinGW in Cerbero is too old.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5155>
VA decoders implementation has been verified from 1.18 through 1.22
development cycles and also via the Fluster test framework. Similar
to other cases, we can prefer hardware over software in most cases.
At the same time, GStreamer-VAAPI decoders are demoted to NONE to
avoid collisions. The first step to their deprecation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2312>
These 10bit formats are identical to NV12_16L32S, but 64bytes of data is being
prefixed with 16bytes data with four pixels of lower 2bits per byte. For
MT2110T, the lower two bits set so each bytes contains a column of 4 pixels,
also describe as tiled lower 2 bits. MT2110T has been chosen as a name to match
the vendor chosen name. This format is unlikely to exist for other vendors.
For MT2110R, the 2 low bits are in raster order.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3444>
When advancing the ringbuffer, store the processed CoreAudio sample
time, then interpolate the clock in the _get_delay() calls to smooth
the clock. CoreAudio's "latency" report is always a constant and
otherwise leads to the clock generating a latency-time staircase.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5140>
Set the BufferFrame size in CoreAudio so it will deliver data
in ringbuffer segment units when recording. Otherwise, CoreAudio
will provide data in whatever granularity it wants, with no
relationship to the requested latency-time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5140>
The current limit is `x10`, which allows just `+20 dB` of gain.
While it may seem sufficient, this came up as a problem
in a real-world, non-specially-engineered situation,
in strawberry's EBU R 128 loudness normalization.
(https://github.com/strawberrymusicplayer/strawberry/pull/1216)
There is an audio track (that was not intentionally engineered that way),
that has integrated loudness of `-38 LUFS`,
and if we want to normalize it's loudness to e.g. `-16 LUFS`,
which is a very reasonable thing to do,
we need to apply gain of `+22 dB`,
which is larger than `+20 dB`, and we fail...
I think it should allow at least `+96 dB` of gain,
and therefore should be at `10^(96/20) ~= 63096`.
But, i don't see why we need to put any specific restriction
on that parameter in the first place, other than the fact
that the fixed-point multiplication scheme does not support volume
larger than 15x-ish.
So let's just implement a floating-point fall-back path
that does not involve fixed-point multiplication
and lift the restriction altogether?
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5063>
Issue was that Qt was caching multiple different shadersbased on a static
variable location. This static variable location was the same no matter
the input video format and so if an item had an input video format of
RGB and another of RGBA, they would eventually end up using the same
GL shader leading to incorrect colours.
Fix by providing different static variable locations for each of the
different shaders that will be produced.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5145>
There is currently no way for applications to know if the stream has
been properly terminated by the server or if the network connection
was disconnected as EOS is sent in both cases.
Adding a property so connection errors can be reported as errors
allowing applications to distinguish between both scenarios.
Fix#2828
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5115>
When this flag is enabled, the transform_caps() simply set passthrough
to generate the raw caps. This is not correct, because the sink and
src have different format/drm-format fields.
We already add system memory conversion for DMABuf manner, so no more
need for this flag.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
The current _nvmm_upload_transform_caps() only simply apply
"memory:NVMM" to all input caps to transform the output caps.
This is not precise and may cause problem. For example, if the
input caps include:
video/x-raw(memory:DMABuf), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
it will be changed as
video/x-raw(memory:GLMemory), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
For GLMemory kind caps, no drm-format should appear.
So we should let it only transforms which it can recognize.
And in _nvmm_upload_accept(), we should only accept the "memory:NVMM"
feature in input caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
The current _directviv_upload_transform_caps() only simply apply
"memory:GLMemory" to all input caps to transform the output caps.
This is not precise and may cause problem. For example, if the
input caps include:
video/x-raw(memory:DMABuf), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
it will be changed as
video/x-raw(memory:GLMemory), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
For GLMemory kind caps, no drm-format should appear.
So we should let it only transforms which it can recognize.
And in _directviv_upload_accept(), we should only accept the system
memory as input caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
The current _gl_memory_upload_transform_caps() only simply apply
"memory:GLMemory" to all input caps to transform the output caps.
This is not precise and may cause problem. For example, if the
input caps include:
video/x-raw(memory:DMABuf), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
it will be changed as
video/x-raw(memory:GLMemory), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
For GLMemory kind caps, no drm-format should appear.
So we should let it only transforms which it can recognize.
And in _gl_memory_upload_propose_allocation(), we should only allocate
the allocator and buffer pool for the caps with "memory:GLMemory"
feature.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
The current _upload_meta_upload_transform_caps() only simply apply
"memory:GLMemory" to all input caps to transform the output caps.
This is not precise and may cause problem. For example, if the
input caps include:
video/x-raw(memory:DMABuf), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
it will be changed as
video/x-raw(memory:GLMemory), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
For GLMemory kind caps, no drm-format should appear.
So we should let it only transforms which it can recognize.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
The current _raw_data_upload_transform_caps() only simply apply
"memory:GLMemory" to all input caps to transform the output caps.
This is not precise and may cause problem. For example, if the
input caps include:
video/x-raw(memory:DMABuf), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
it will be changed as
video/x-raw(memory:GLMemory), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
For GLMemory kind caps, no drm-format should appear.
So we should let it only transforms which it can recognize.
We also should recognize the system memory caps in _accept() early, if
the input is not system memory, we just return early.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
Most of the time, the RGB kind formats are OpenGL native supported
format which has only one plane. They can be imported at one shot
using no matter DIRECT or INDIRECT mode.
While YUV kind formats which have multi planes have two ways to import.
They can be DIRECT imported, which requires GL_OES_EGL_image_external
extension. The output format should be RGBA and TARGET should be set
as OES after imported. The other way, they can be INDIRECT imported,
which makes each plane as a texture. In this mode, the imported textures
have different fourcc from the original format. For example, the NV12
format can be imported as a R8 texture for the first plane and RG88
texture for the second plane. The output TARGET should be sets as 2D
in this mode.
When converting sink caps to src caps, we first filter the feature of
"video/x-raw(memory:DMABuf)" and system memory. Then Based on the
external_only flag (INDIRECT mode does not care while DIRECT mode cares),
we transform the drm-format into the gst video format.
When converting src caps into sink caps, we first filter the correct
TARGET(INDIRECT mode contains 2D only while DIRECT mode contains 2D,
OES or both of them) gstructure. Then Based on the include_external flag
(INDIRECT mode always true while DIRECT mode depends on TARGET), we
transform the gst video format into drm-format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
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/5126>
Pass GstVideoInfoDmaDrm or GstVideoInfo whenever possible, avoiding passing
strange combination of GstVieoFormat + modifier. Even though we don't have any
at the moment, this also allow supporting GstVideoFormat that are not supported
in our DRM integration.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5120>
When we fill a bitstream buffer the buffer might be too small to hold
the entire frame. Only resize to the filled size, preventing the
following assertion to happen.
gst_buffer_resize_range: assertion 'bufmax >= bufoffs + offset + size' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5100>
Shader compilation was failing on macOS:
gstglslstage.c:519:_compile_shader:<glslstage1> fragment shader compilation failed:
ERROR: 0:10: 'input_swizzle' : syntax error: Array size must appear after variable name
Co-authored-by: Matthew Waters <matthew@centricular.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5123>
According to libva API description, cu_qp_delta in VAConfigAttribValEncHEVCFeatures
is supposed to be used as a flag not the value of depth. And if flag enabled,
diff_cu_qp_delta_depth should be decided by log2_diff_max_min_luma_coding_block_size.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5068>
Rework the va_map_unlocked() after we keep mapping behavior (whether to
use derive) consistent with allocator_try stage. Also remove the flag
for iHD case because pitch/stride difference between vaCreateImage and
vaDeriveImage only possibly happen on iHD by now.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5046>
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/5046>
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/5021>
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/5097>
vtenc has an async output queue, which we only iterate over after another frame is enqueued.
At the very least it means we're always a frame behind the fastest possible output.
In edge cases it's also bug-prone - for example if we only have 1 frame, the downstream caps negotiation
will never happen.
This commit adds a separate task running on the source pad, which only iterates over the output queue
and pushes frames out as soon as they're put there. The queue length is limited to ensure we don't encode
too far ahead compared to what downstream can consume. Any failures that occur when pushing data downstream
will be signalled in self->downstream_ret so that other parts of code can act accordingly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4967>
Don't assume that compositor will output only single buffer
for single input buffer. If buffer's running time is not completly
aligned to output buffer running time or duration, compositor
can generate multiple buffers. If that happens, two threads,
one is aggregator output thread and main thread were trying
to modify buffer in this test. Clear the buffer after
shutting down pipeline to avoid the race.
Fixes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2836
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5081>
Newer macOS provides /usr/lib/pkgconfig/libpcre2-8.pc which is broken
because it says headers are in /usr/include but that directory doesn't
exist. It can only be used to find the library, which only exists on
newer macOS at /usr/lib/libpcre2-8.dylib, so it's also unusable.
So, force usage of the subproject for glib.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5060>
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/5059>
Sending an EOS event is actually really bad because rtpbin doesn't
handle that very well. It was only being used as a way to notify
webrtcbin to check if re-negotiation is needed.
We don't need that anymore, since changing the direction is enough to
notify webrtcbin to check for re-negotiation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5045>
When a video track is muted, hide the video element to differentiate
it from a track that is stuck because we stopped receiving RTP data.
Show it again when it is unmuted.
When a video track is removed, remove the video element. It will be
re-added on renegotiation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5045>
The current way of dma caps uses the drm-format to replace the orginal
format field. The absence of format field means it can accept all formats.
It causes problems when clipping with other old DMA or video/x-raw(ANY)
caps, the result will contain both format field and drm-format field,
which is not valid DMA caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4981>
This GST_VIDEO_FORMAT_DMA_DRM is introduced for DMABuf kind feature
usage. It represent the DMA DRM kind memory. And like the ENCODED
format, it should not be interpreted and mapped as normal video format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4981>
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/5048>
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/5028>
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/4912>
This check fixes a critical warning that can happen when a pointer motion
happens and the video doesn't have its width/height information available.
GStreamer-Video-CRITICAL **: gst_video_center_rect: assertion 'src->h != 0' failed
#0 g_logv (log_domain=0x7ffff705e176 "GStreamer-Video", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=<optimized out>) at ../../../../Projects/jhbuild/glib/glib/gmessages.c:1422
#1 0x00007ffff7e1a81d in g_log (log_domain=<optimized out>, log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff7e77a9d "%s: assertion '%s' failed") at ../../../../Projects/jhbuild/glib/glib/gmessages.c:1460
#2 0x00007ffff7e1b749 in g_return_if_fail_warning (log_domain=<optimized out>, pretty_function=<optimized out>, expression=<optimized out>) at ../../../../Projects/jhbuild/glib/glib/gmessages.c:2930
#3 0x00007ffff701d90b in gst_video_sink_center_rect (src=..., dst=..., result=result@entry=0x7fffffffc6d0, scaling=scaling@entry=1) at ../../../../Projects/jhbuild/gstreamer/subprojects/gst-plugins-base/gst-libs/gst/video/gstvideosink.c:105
#4 0x00007fffe5652dbb in _fit_stream_to_allocated_size (result=0x7fffffffc6d0, allocation=0x7fffffffc6c0, base_widget=0x9396f0) at ../../../../Projects/jhbuild/gstreamer/subprojects/gst-plugins-good/ext/gtk/gtkgstbasewidget.c:326
#5 gtk_gst_base_widget_display_size_to_stream_size (base_widget=base_widget@entry=0x9396f0, x=1207.7109375, y=811.84765625, stream_x=stream_x@entry=0x7fffffffc720, stream_y=stream_y@entry=0x7fffffffc728) at ../../../../Projects/jhbuild/gstreamer/subprojects/gst-plugins-good/ext/gtk/gtkgstbasewidget.c:344
#6 0x00007fffe5651a4b in gst_gtk_base_sink_navigation_send_event (navigation=0x5ff990, event=0x178a730) at ../../../../Projects/jhbuild/gstreamer/subprojects/gst-plugins-good/ext/gtk/gstgtkbasesink.c:340
#7 0x00007fffe5652432 in gtk_gst_base_widget_motion_event (widget=<optimized out>, event=event@entry=0x1f14b60) at ../../../../Projects/jhbuild/gstreamer/subprojects/gst-plugins-good/ext/gtk/gtkgstbasewidget.c:404
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5049>
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/5038>
The videoencoder base class uses getcaps() to ask a subclass for the caps in its
sink_query_default() implementation.
Replace the custom handling of the QUERY_CAPS in the v4l2videoenc with an
implementation of getcaps() that returns the caps that are supported by the
v4l2videoenc to return these caps in the query.
This getcaps() implementation also calls the provided proxy_getcaps(), which
sends a caps query to downstream. This fixes the v4l2videoenc element to respect
limits of downstream elements in a sink query.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5034>
