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>
Given the amount of complains about artifacts when negotiating dmabuf
given incompatible drm-formats, and that there's no enough bandwidth
for a proper and quick fix in gstreamer-vaapi, this patch disables,
from decoders and postprocessor, the DMABuf caps feature.
For those who needs DMABuf can use the va elements in -bad, increasing
their ranking for autoplugging by using the environment variable
GST_PLUGIN_FEATURE_RANK=vah264dec:MAX, for example.
This can be considered a first step to the deprecation of
gstreamer-vaapi in favor of the va plugin in -bad.
Fixes: #1137
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5010>
The videoencoder base class always uses the negotiated allocator for allocating
coded buffers and ignores the negotiated buffer pool. Therefore, the
v4l2videoenc always has to copy buffers from the pool into the allocated
output buffers.
This breaks downstream elements that want to import the CAPTURE buffers of the
v4l2videoenc, since the v4l2videoenc copies the exported CAPTURE buffers and
sends the copies downstream.
Always use the CAPTURE buffer pool for acquiring CAPTURE buffers instead of
allocating the buffers in the base class.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4230>
It's possible and normal to tear down a harness while the pipeline is
running. At the same time, it's desired for the
`gst_harness_pad_link_tear_down()` function to be synchronous.
This has created the conflict where the main thread may request a
harness to be torn down while it's in use or about to be used by a pad
in the streaming thread.
The previous implementation of `gst_harness_pad_link_tear_down()` tried
to handle this by taking the stream lock of the harnessed pad and
resetting all the pad functions while holding it. That approach was
however insufficient to handle the case where a non-serialized event
or query is being handled or about to be handled in a different thread.
This edge case was one race condition behind the flakes in the flvmux
check tests -- the rest being covered by https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2803.
This patch fixes the problem by adding an intermediate ref-counted
object, GstHarnessLink, which replaces the usage of the HARNESS_KEY
association. GstHarnessLink allows the pad functions such as event,
query and chain to borrow a reference to GstHarness and more
importantly, to lock the GstHarnessLink during their usage to block
(delay) its destruction until no users are left, and guarantee that any
future user will not receive an invalid GstHarness handle past its
destruction.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5017>
This reverts commit 893e4ed0dd.
This caused regressions in existing elements which override/set things
like QoS and such in their own init functions. If the base class does
this in ::constructed() now it will override the subclass settings
again with its own, which can have unintended side-effects.
Case in point is gdkpixbufsink which disabled QoS there, and this
patch would reliably make the unit test fail in valgrind because
now frames are dropped because of QoS (when QoS should really be
disabled).
Fixes#2794
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5006>
If the capture pool is already active, like when handling gaps at the
start of a stream, do not setup the decoder to wait for src_ch event.
Otherwise the decoder will endup waiting for that at the wrong moment
and exit the decoding thread unexpectedly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4590>
Fix this pipeline where the tag list is not writable:
gst-launch-1.0 videotestsrc ! taginject tags="image-orientation=rotate-90" ! videoflip video-direction=auto \
! autovideosink
GStreamer-CRITICAL **: 12:34:36.310: gst_tag_list_add: assertion 'gst_tag_list_is_writable (list)' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4987>
This fixes a build error if Qt was build without accessibility support:
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:
In member function 'bool GstQuickRenderer::init(GstGLContext*, GError**)':
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:341:13:
error: 'QCoreApplication' was not declared in this scope; did you mean 'QApplication'?
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:341:31:
error: 'app' was not declared in this scope
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:341:37:
error: 'QCoreApplication' is not a class, namespace, or enumeration
[...]
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:458:5:
error: 'QEventLoop' was not declared in this scope; did you mean 'QEvent'?
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:459:9:
error: 'loop' was not declared in this scope
If accessibility is enabled, the includes for QCoreApplication and QEventLoop
are indirectly pulled via QWidget.
Add the required headers as documented in [1] and [2].
[1] https://doc.qt.io/qt-5/qcoreapplication.html
[2] https://doc.qt.io/qt-5/qeventloop.html
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4815>
Previously, we would create a new GstMemory per write operation
and then append them to the GstBuffer. This would cause a reallocation
every 16 Memories which is an issue since the png encoder will usually
do write in a pattern of 4, 8 and 8k bytes repeating until the frame
is done.
Instead allocate a single GstMemory and keep writting it into it
with a manual index. Much like the jpegenc does.
Doing some basic testing With a testsrc snow pattern at 4k and 8k
the same pipeline would take ~3.30s to encode a 4k frame and ~23s
for an 8k. At 4k 0.70s/33% is taken by memory allocations, while at
8k its ~10.5s/45%.
With this patch, at 4k the pipeline takes ~2.40s and at 8k only 9.60s
making this 28% and 58% faster accordingly on my laptop, and
allocation runtime is dropped to subsecond times.
Here's the test pipeline used, increase num-buffers in image freeze
to gather more samples.
```
gst-launch-1.0 videotestsrc num-buffers=1 pattern=snow ! imagefreeze num-buffers=1 ! \
video/x-raw,width=7680,height=4320 ! pngenc ! fakesink
```
Close#2717
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4944>
lc3enc:
- encodes raw audio into lc3 format
- uses the default bitrate property and frame duration
from the caps to determine the byte count of
the encoded frames if it is not specified in
the downstream caps after negotiation
- uses the same byte count value for all the channels
- all the common session configuration parameters
are passed in the src caps
lc3dec:
- decodes an lc3 encoded audio
- sink caps should contain all the common session configuration
params
- uses frame_duration and frame_bytes (byte count) in the sink
caps as parameters along with sample rate and channel count
- byte count is same for all the channels
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4376>
`srt_rejectreason_str` doesn't give us a unique string for every
possible reason. Peers can define their own reasons and SRT just gives
us the string `"Application-defined rejection reason"` for all of them.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4948>
When gst_element_set_state is called in _setup_locked and errors, the
callback is already processed before we reach handle_current_async, and
the timer is started even though it's finished processing, which results
in a NULL pointer crash later in async_timeout_cb.
To fix this, we check that it's still processing before calling
handle_current_async.
Fixes#1683
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4936>
The aim of this example is to show how to make use of the accept-certificate
signal from a GTK GUI, and prompt user in case of invalid certificate.
There are two subtleties to be aware of:
1. the signal is emitted from the GStreamer streaming thread, therefore the
caller can't modify the GUI straight away, instead they must do it from the
main thread (eg. by using g_idle_add())
2. in case of a redirection, then a TLS failure, the caller won't know
about the redirection. Actually, it's possible to be notified of the
redirection by watching "message:element" and inspecting http-headers,
but even in that case, the signal will be received *after* the signal
"accept-certificate" (even though the redirection happened *before*).
This second point is tricky. It's not uncommon to have servers that redirect
http requests to https. So errors of the type "HTTP -> HTTPS -> TLS error"
happen, and if the caller doesn't care about redirection, they might prompt
users with a message such as "TLS error for URL http://...", which wouldn't make
much sense.
This example shows how to handle that right, by connecting to the signal
"message:element", inspecting the http-headers, and in case of redirection,
updating the TLS error dialog to indicate that the request was redirected.
Here are a few examples of streams that exhibit TLS failure (at the time of
this commit, of course):
* https://radiolive.sanjavier.es:8443/stream: unknown-ca
* https://am981.ddns.net:9005/stream.ogg: unknown-ca
* http://stream.diazol.hu:7092/zene.mp3: redir then bad-identity
* https://streaming.fabrik.fm/izwi/echocast/audio/index.m3u8: unknown-ca
(this one is a HLS stream)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4925>
With libsoup 2.x, it was possible to know when there was a TLS failure, as
libsoup provided the "special http status code" SOUP_STATUS_SSL_FAILED.
However these special codes were dropped with libsoup 3.x: now libsoup emits
the accept-certificate signal when there's a TLS failure.
This commit adds a signal "accept-certificate" to SoupHttpSrc, which is in fact
just about forwarding the signal from SoupMessage (which is, itself, forwarded
from GTlsConnection). Note that, in case of libsoup 2.x, the signal is never
emitted.
Fixes: #2379
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4925>
Adding new subtitle overlay element. It's a bin which is wrapping
two internal elements dwritesubtitlemux and dwritetextoverlay.
* dwritesubtitlemux: A new internal element to aggregate subtitle
buffers and to attach the aggregated subtitle buffers on
video buffer as meta.
* dwritetextoverlay: Extracts/renders the subtitle meta and
discard the meta after rendering.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4934>
In the current implementation, we support for most pixel format left
and top padding by changing the offset in the video meta. Though, to
align driver bytesused to the offset, we recalculate the offset, which
removed the modification we did before.
Instead, save the plane size, and truncate the driver reported bytesused
to the expected size, which ensures that the offsets still match. This
should also fix issues were the buffer size ended up bigger then the
pool size due to driver introduced padding.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4920>
There's no reason to release GstMemory manually at all.
If we do release GstMemory, corresponding GstBuffer will be
discarded by GstBufferPool baseclass because the size is changed
to zero.
Actual cause of heavy CPU usage in case of fixed-size pool
(i.e., decoder output buffer pool) and if we remove GstMemory from
GstBuffer is that GstBufferPool baseclass is doing busy wait in acquire_buffer()
for some reason. That needs to be investigated though, discarding
and re-alloc every GstBuffer is not ideal already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4935>
Fixes test: validate.uridecodebin.expose_raw_pad_caps
testsrcbin (currently part of debugutilsbad) is an useful element for
validate tests.
validate.uridecodebin.expose_raw_pad_caps makes use of it.
Unfortunately, because validate tests with GStreamer only run with
whitelisted plugins and `debugutilsbad` wasn't in the whitelist, the
test was failing and being auto-skipped.
This patch adds debugutilsbad to the whitelists used by validate tests
in subprojects with a validate/meson.build.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4931>
The current way of using gst_video_info_set_format() will change all
fields of the GstVideoInfo. We only need to change its format, stride
and offset fields.
In order to keep the consistency with th common drm API, we rename the
gst_va_video_info_from_dma_info() into gst_va_dma_drm_info_to_video_info().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4883>
The current way only selects the best video format from the first
structure of the caps. The caps like:
video/x-raw(memory:VAMemory),drm-format=(string)NV12; \
video/x-raw(memory:VAMemory),format=(string){ NV12, Y210 }
Will just choose NV12 as the result, even the bitstream is 10 bits.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4928>
ges-timeline-element property getter handler was using
g_value_take_object() with internal pointers of the element as
arguments, instead of g_value_set_object().
g_value_take_object() moves the ownership of the reference; hence,
when reading "timeline" the reference ownership of timeline is moved
away from the ges-timeline-element and into the GValue.
Since GValues are temporaries that are often discarded quickly after,
this can easily lead to a double free. This was causing
gst-editing-services / pythontests to crash when running
TestTrackElements.test_ungroup_regroup() because of an innocent read of
`clip2.props.timeline` around the end of the test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4924>
Some NLE tests were calling ges_init() from the test suite
initialization function. This was causing them to deadlock when running
with glib 2.76.3.
ges_init() causes a GThreadPool to be initialized. Even if GES at this
point doesn't request any thread to be created, since glib 2.63.4+
(see 8aeca4fa64)
the first time a GThreadPool is initialized a "pool-spawner" thread is
created, which is later used by g_thread_pool_push().
The default behavior of the GStreamer check tests is to fork for every
test case. This is not safe if any thread has been created at this
point. In this particular case, GThreadPool preserves the state that
says a "pool-spawner" thread has been created, and will have access to
its mutex and condition variable, but their queues will have different
contents as the memory has been forked. In consequence, calls to
g_thread_pool_push() will deadlock.
The deadlock will not occur if running the tests with CK_FORK=no.
This patch modifies the affected tests to only call ges_init() from
inside the test cases, fixing the deadlock.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4915>
A significant portion of the NLE test suite was often timing out due to
the tests taking way longer than necessary because the sinks were
synchronizing to the clock, which is the default behavior for
fakevideosink and fakeaudiosink.
Notable was the case of nleoperation.c:test_pyramid_operations, that ran
through a 10 second stream twice. As the default timeout is 20 seconds,
this made the test flaky.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4914>
Refusing an incoming segment in < GST_MATROSKA_READ_STATE_DATA should only be
done if the incoming segment is not in GST_FORMAT_TIME.
In GST_FORMAT_TIME, we are just storing the values and returning, so we can
invert the order of the checks.
Fixes proper segment propagation in matroska/webm DASH use-cases
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3914>
Is a seek is done on stream-collection post, there are no selected streams
yet. Therefore none would be chosen to adjust the key-unit seek.
If no streams are selected, fallback to a default stream (i.e. one which has
track(s) with GST_STREAM_FLAG_SELECT).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3914>
When seeking is handled by the collection posting thread, there is a possibility
that some leftover data will be pushed by the stream thread.
Properly detect and reject those early segments (and buffers) by comparing it to
the main segment seqnum
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3914>
As VK_FORMAT_FEATURE_2_xxx are defined as static const variable, the
vscoce C compiler prevents the initialization of the vk_usage_map
structure with error "C2099: initializer is not a constant".
Init the structure separately.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4904>
The current way of using parent's copy_metadata() virtual function will
selectively filter out some meta such as crop meta. That virtual function
should be used when copying input buffer's meta data into output buffer,
not suitable when importing the input buffer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4887>
When the input buffer has crop meta, and we need to do copy, we
should consider the uncropped video size and copy the full size
of video memory.
The video meta in this case should contain the full uncropped
resolution info. We can use it to create full size va buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4887>
Adding Direct3D11 backend Qt6 QML videosink element, qml6d3d11sink.
Implementation details are similar to the qt6 plugin in -good
but there are a few notable differences.
* qml6d3d11sink accepts all GstD3D11 supported video formats (e.g., NV12).
* Scene graph (owned by qml6d3d11sink) will hold dedicated and sharable
RGBA texture which belongs to Qt6's Direct3D11 device, instead of sharing
GStreamer's own texture with Qt6.
* All rendering operations will be done by using GStreamer's Direct3D11 device.
Specifically, upstream texture will be copied (in case of RGBA)
or converted to the above mentioned Qt6's sharable texture.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3707>
... otherwise streams with constant size samples defined with a single
`sample_size` for all samples in the `stsz` box fall in the category
`chunks_are_samples` in `qtdemux_stbl_init`, overriding the actual
sample count.
`FOURCC_soun` would set this automatically for `compression_id == 0xfffe`,
however `compression_id` is read from the Audio Sample Entry box at an offset
marked as "pre-defined" in some version of the spec and set to 0 both by
GStreamer and FFmpeg for opus streams.
Considering the stream `sampled` flag is set explicitely by other fourcc
variants, doing so for opus seems consistent.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4903>
This will cause an integer overflow a little bit further down because we
allocate a bit more memory to allow for a NUL-terminator.
The caller should've avoided passing that much data in already as it's
not going to be a valid image and there's likely not even that much data
available.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4894>
This is a small optimization and avoids restarting the next parsing
iteration on already accepted data.
On its own it would also fix ZDI-CAN-20968 (see previous commit) but the
previous commit independently is also a valid fix for it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4895>
The "Encapsulation of Opus in ISO Base Media File Format" [1] specifications,
§ 4.3.2 Opus Specific Box, indicates that data must be stored as big-endian.
In `build_opus_extension`, `gst_byte_writer_put*_le ()` variants were used,
causing audio streams conversion to Opus in mp4 to offset samples due to the
PreSkip field incorrect value (29ms early in our test cases).
[1] https://opus-codec.org/docs/opus_in_isobmff.html#4.3.2
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4875>
Now all codec baseclasses can inform subclasses of correct max DPB size,
and exception handling (e.g., emergency bumping in h.264) has been
improved as well. Smaller number of additional DPB frame allocation
seems to be safe.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4878>
Adding GST_CUDA_CRITICAL_ERRORS env variable so that program can be
terminated on unrecoverable error.
Example)
GST_CUDA_CRITICAL_ERRORS=2,700 gst-launch-1.0 ...
In this example, CUDA_ERROR_OUT_OF_MEMORY(2) and
CUDA_ERROR_ILLEGAL_ADDRESS(700) are registered as critical error
and program will be aborted on those errors
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4729>
If two senders use the same multicast IP and port then new_session_pad()
may try to add a srcpad to the same stream twice.
stream->srcpad is updated but gst_element_add_pad() fails the second
time. As a result stream->srcpad points to a deleted object and
access in gst_sdp_demux_stream_free() fails with a segfault.
Just ignore the second pad. Nothing useful can be done with it anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4603>
- Adding bayer 10,12,14,16 bits components with 16 bits storage. These
changes only adds capabilities. Capability format string is a complete
description of the frame and pixels layout. Only mapping LE bayer
formats as v4l2 only define LE bayer formats.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4852>
The `gst_video_decoder_negotiate_pool` function expects the
`decide_allocation` function to always provide a pool and will fail to
negotiate if the pool is missing. If we return immediately (even if we
don't need to do anything special) negotiation will fail if the
downstream element does not propose a pool.
Fix by chaining up to the default `decide_allocation` function which
adds a fallback pool if one was not already proposed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4630>
Adding DirectWrite text rendering elements
* dwriteclockoverlay: Equivalent to clockoverlay
* dwritetimeoverlay: Equivalent to timeoverlay
* dwritetextoverlay: Similar to textoverlay but subtitle is not
supported
Newly added elements support system memory and d3d11 memory
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4826>
This new property allows setting of PES stream number for AAC audio
and AVC video streams.
The stream number is subject to the following constraints:
1. it must be between 0 and 15 for video
2. it must be between 0 and 31 for audio
Currently the PES stream number is hard-coded to zero for these
stream types.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4822>
Add support for 10/12/14/16 bit depths . This consists of multiple parts.
First is the parsing of caps, which pulls out the bitness and endianness
from the video/x-bayer format.
Second, gst_bayer2rgb_split_and_upsample_horiz() is split into two similar
functions, one for 8bit bayer handling and another for 16bit bayer handling.
The content is basically identical, except one uses 8bpp and the other 16bpp
inputs and outputs, and they each use different ORC code to match. The 16bpp
variant also handles endian swapping. There is now a wrapper called
gst_bayer2rgb_split_and_upsample_horiz() which selects the correct function
based on bpp from the parser.
Third, gst_bayer2rgb_process() is extended to handle both 8bit and 16bit
bayer data. Yet again there are matching ORC functions to handle the 16bit
data. This time however the 16bit handling of data is slightly special. The
ORC is not able to emit opcodes for 'x2 mergelq', so the trick here is to
store the BG and GR longs into separate 'dtmp' temporary buffer, and then
do one more ORC post-processing step, compensate for the less-than-16bpp
bitness using left shift, and reorder them into the destination frame
using 'mergelq' .
Example usage:
```
$ gst-launch-1.0 videotestsrc ! \
video/x-bayer,width=512,height=512,format=bggr16le ! \
bayer2rgb ! \
video/x-raw,format=RGBA64_LE ! \
videoconvert ! \
autovideosink
```
Example usage:
```
$ gst-launch-1.0 videotestsrc ! \
video/x-raw,width=512,height=512,format=ARGB ! \
rgb2bayer ! \
video/x-bayer,format=bggr12le ! \
bayer2rgb ! \
video/x-raw,format=RGBA64_LE ! \
videoconvert ! \
autovideosink
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Add comments regarding which LINE()s point to which data in the
temporary buffer and a large comment explaining how the buffer
is processed. This will hopefully be useful to someone, as the
code is not obvious. No functional change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Instead of passing a single element of GstBayer2RGB structure into the
gst_bayer2rgb_split_and_upsample_horiz(), pass the entire pointer and
let the funciton pick out whatever it needs out of the structure. This
is a preparatory patch. No functional change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Pass all three parameters used by the LINE() macro to the LINE() macro
and unroll the code for readability. Add more comments regarding which
of these LINE()s point to which data in the temporary buffer to make
the code less confusing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
The j variable is used as an iterator further down in this code, but
here it can be just inlined in the macro parameters to make the code
easier to read. This is done in preparation for further changes. No
functional change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
The bayer2rgb process implemented doesn't support in-place tranform.
This element doesn't implement a "transform_ip" vmethod of
GstBaseTransform it will revert to using the "tranform" vmethod.
It's misleading to set it to TRUE, here. Change this to FALSE.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Add support for conversion to 10/12/14/16 bit bayer pattern.
The implementation is rather simplistic, just take the ARGB
input, generate 16-bit data out of it instead of 8-bit, shift
them as required by the output bitness, and apply endian swap.
Example usage:
```
$ gst-launch-1.0 videotestsrc num-buffers=1 ! \
video/x-raw,width=512,height=512,format=ARGB ! \
rgb2bayer ! \
video/x-bayer,format=bggr12le ! \
filesink location=/tmp/bayer12.raw
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Add support for generation of 10/12/14/16 bit bayer test pattern.
The implementation is rather simplistic, just take the ARGB
input, generate 16-bit data out of it instead of 8-bit, shift
them as required by the output bitness, and apply endian swap.
Example usage:
```
$ gst-launch-1.0 videotestsrc ! \
video/x-bayer,width=512,height=512,format=bggr12le ! \
bayer2rgb ! \
video/x-raw,format=RGBA64_LE ! \
videoconvert ! \
autovideosink
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Even if we don't yet know what the echo probe format is, we want to be able to
provide silence for the reverse path, so that when the probe becomes available,
there is no ambiguity around what time period the new set of samples are for.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4849>
The probe's info may not precisely match the dsp's info. For instance,
the number of channels or their layout might be different.
```
GStreamer-Audio-CRITICAL **: 16:21:32.899: the GstAudioInfo argument is not equal to the GstAudioMeta's attached info
```
This broke in d5755744c3.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4849>
Race condition without this patch:
- srcpad task is being stopped in gst_aggregator_stop_srcpad_task()
- at that moment, in pre-queue event handler, gst_pad_get_task_state()
returned GST_TASK_PAUSED
- then in srcpad task got stopped in gst_aggregator_stop_srcpad_task()
- finally srcpad task got resumed in pre-queue event handler
To address it, checks "running" flag in pre-queue event handler.
Both pre-queue stream-start event handler and "running" flag
are protected by SRC_LOCK already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4847>
A race condition can occur in `srtpdec` during the READY -> NULL transition:
an RTCP buffer can make its way to `gst_srtp_dec_chain` while the element is
partially stopped, resulting in the following critical warning:
> Got data flow before segment event
The problematic sequence is the following:
1. An RTCP buffer is being handled by the chain function for the
`rtcp_sinkpad`. Since, this is the first buffer, we try pushing the sticky
events to `rtcp_srcpad`.
2. At the same moment, the element is being transitioned from PAUSED to READY.
3. While checking and pushing the sticky events for `rtcp_srcpad`, we reach the
Segment event. For this, we try to get it from the "otherpad", in this case
`rtp_srcpad`. In the problematic case, `rtp_srcpad` has already been
deactivated so its sticky events have been cleared. We won't be pushing any
Segment event to `rtcp_srcpad`.
4. We return to the chain function for `rtcp_sinkpad` and try pushing the
buffer to `rtcp_srcpad` for which deactivation hasn't started yet, hence the
"Got data flow before segment event".
This commit:
- Adds a boolean return value to `gst_srtp_dec_push_early_events`: in case the
Segment event can't be retrieved, `gst_srtp_dec_chain` can return an error
instead of calling `gst_pad_push`.
- Replaces the obsolete `gst_pad_set_caps` with `gst_pad_push_event`. The
additional preconditions checked by previous function are guaranteed here
since we push a fixed Caps which was built in the same function.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4844>
A race condition can occur in `srtpdec` during the READY -> NULL transition:
an RTCP buffer can make its way to `gst_srtp_dec_chain` while the element is
partially stopped, resulting in the following critical warning:
> assertion 'parent->numsinkpads <= 1' failed
This can occur when the first RTCP buffer is received during the READY -> NULL
transition. If deactivation of the `rtp_srcpad` has already reached
`post_activate`, the sticky events are removed from this Pad. In this case,
`gst_srtp_dec_push_early_events` branches to the generation of a stream id
using `gst_pad_create_stream_id`. This function ensures that the element
doesn't own more than 1 sink pad. Since `srtpdec` owns two of them, the
assertion fails.
This commit uses `gst_element_decorate_stream_id` which doesn't perform this
check. The preconditions is not necessary in this particular context since the
stream id for the RTP / RTCP pads are derived from the same id.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4844>
Change the internal GstVideoInfo structure in the GstVaDmabufAllocator to
GstVideoInfoDmaDrm in order to keep track of the exported DRM format by the
driver, and thus removing the DRMModifier quark attached as qdata in the
GstMemory. Though, the exposed API isn't updated yet; that has to go in a
second iteration.
Also this patch clean up some code (remove an unused buffer size assignation)
and fix some typos in documentation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4821>
The VA has its internal video format mapping(because different drivers may
have different interpretation for the same format), so we should convert the
info in GstVideoInfoDmaDrm into the according video info based on that mapping.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4821>
Some surface formats such as GST_VIDEO_FORMAT_Y42B and GST_VIDEO_FORMAT_RGB
can be created but can not be exported as DMA buffer. You can not say that
this is a driver bug because the driver may never want to share this kind of
surface out of libva.
And this function will be used to detect modifiers later, so the error message
will be annoying.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4821>
The proxy callback for the notify::last-message was emiting the signal
again on the child, which caused an infinit loop. We could swap the child
and the user data to signal to the bin instead, but it was found that proxying
this signal was not very useful. Typical use case it to set silent=0 and use
deep-notify feature. Proxying that signal just duplicate that output which
isn't very useful.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4766>
If the time server is restarted with a time in the past the net client
clock will not report the new time anymore as this would mean that the
clock moves back in time which it does not do.
Now the clock will be kept alive but marked as corrupted and will not
be re-used from the cache.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4802>
When doing a segment seek, the base offset in the new segment
would be increased by segment.position which is basically the
timestamp of the last packet. This does not include the duration
of the last packet though, so might be slightly shorter than the
actual duration of the clip or the requested segment.
Increase the base offset by the segment duration instead when
accumulating segments, which is more correct as it doesn't cut
off the last frame and makes the effective loop segment duration
consistent with the actual duration returned from a duration
query.
In case a segment stop was specified it's also possible that
some data was sent beyond the stop that's necessary for decoding
so the base offset increment should be based on that then and
not on the timestamp of the last buffer pushed out.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4604>
glfilter will unref input buffer after _transform() call immidiately,
but gpu may still reading input buffer for rendering because gl
api is executed async. Need hold reference for input buffer by
adding parent meta to output buffer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4801>
