Instead of having each tracer implement its own parameter parsing,
centralize the handling in the tracer subsystem using GstStructure.
This simplifies tracer implementations and provides a consistent way
to handle properties.
It also allows for much better documentation by forcing tracer object
to expose properties
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8086>
There is no reason why we should mandate people to "at least" use the static
sink pad. This caused issues, like mandating that it should always have valid
content linked to it (problematic in case of upstream stream changes).
Instead we only use it if it's actually linked to, in which case it gets added
to the list of inputs.
This actually simplifies the code too.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7949>
When checking whether a no-longer used output could be re-used for another slot,
we only want to do that for streams which are not still used.
Otherwise we end up potentially re-assigning a demuxer stream to a completely
different one
Furthermore, if we *are* re-using an output slot, indicate what the replacement
GstStream will be so slot matching can work properly (which can happen in the
case of demuxers which add/remove all pads even if only a single one changed)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7949>
This relation type define relations between each components of two groups.
First component of first group relate to first component of second group,
Second component of second group relate to second component of second group,
and so on. It's a denser way to express relations in this context.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8087>
There was different behaviour if the proxy was configured through
properties or environment. For properties libcurl would be configured
with any auth, but for environment libcurl would default to using basic.
Now any auth is set for both configuration methods.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7935>
The Content-Length header would unconditionally be included when the
proxy property was set. This would result in requests with both
Content-Length and Transfer-Encoding header. Now we rely on the
use-content-length property in the proxy case aswell. This also makes
sure that Content-Type is set correctly, since before that would be
skipped if proxy was used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7935>
If a new fragment is added with a valid duration but no offset then the start
offset is set later based on the end offset of the previous fragment. At that
point the end offset of this fragment can also be calculated and not doing so
would give the next fragment the same start offset.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8069>
Allow sample rate, number of channels and bps to change and in that case update
the caps accordingly.
Also move (non-fatal) validity checks and storing of the header values outside
the actual parsing once we actually know that a valid frame is available.
And also don't warn on the last frame with fixed block size blocking strategy
that the block size has changed: the last frame is allowed to be smaller.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3281
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8075>
We get loads of warnings when parsing videos from users:
gsth264parser.c:1115:gst_h264_parser_parse_user_data_unregistered: No more remaining payload data to store
gsth264parse.c:646:gst_h264_parse_process_sei:<h264parse0> failed to parse one or more SEI message
Those are raised because of unregistered SEI without user data.
The spec does not explicitly state that unregistered SEI needs to have
data and I suppose the UUID by itself can carry valuable information.
FFmpeg also parses and exposes such SEI so there is no reason for us no
too as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7931>
It creates a new structure for passing the codec quality structure at _start(),
where it will be filled. The quality level can be set or changed according
encoder limits.
Later the quality level will be set at _update_session_parameters() and at each
frame encoding. That's why it has to be set at _start().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8007>
The algorithm for generating the current slot index is a simple round robin,
nonetheless it's not assured that the next slot index it's not still used by a
still living encode picture.
This new way holds an array with the still living encode pictures and the next
slot index looks for a released index in the array.
Its downside is deallocating a picture need to be removed from the array, so the
helper has to be passed to the uninit() function
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8007>
In GStreamer that buffer information is decoupled, holding other structures to
describe the stream: GstCaps. So, to keep the GStreamer design this patch
removes these information from GstVulkanEncoderPicture and pass to
gst_vulkan_encoder_encode() a pointer to GstVideoInfo.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8007>
Instead of holding all headers in an external array and add them into the
bitstream buffer before the encoding operation, adding extra memory and extra
copy operations, the encoder picture should specify the offset where the Vulkan
will start to add the bitstream slices/frame, because the element has written
already the headers until that offset.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8007>
That's the number of references that gst_vulkan_encoder_encode() receives to
process, so it has to go as a parameter, because it's part of the reference
list, not of the picture.
This commit also modified unit tests accordingly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8007>
The structure already stored the generic video capabilities and the specific
codec capabilities both for encoding an decoding. The generic decoder
capabilities weren't stored because it was only used internally in the decoder
helper object. Nonetheless, for the encoder, the elements will need the generic
encoder capabilities to configure the encoding. That's why it's required to
expose it as part of GstVulkanVideoCapabilities. And the generic decoder is
included for the sake of symmetry.
While updating the API vkvideoencodeh265 test got some code-style fixes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8007>
While this specific case is also caught when initializing co_chunk, the error
is ignored in various places and calling into the function would lead to out of
bounds reads if the error message doesn't cause the pipeline to be shut down
fast enough.
To avoid this, no matter what, make sure enough offsets are available when
parsing them. While this is potentially slower, the same is already done in the
non-chunks_are_samples case.
Thanks to Antonio Morales for finding and reporting the issue.
Fixes GHSL-2024-245
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3847
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8059>
The level in GstAudioLevelMeta is represented as a signed 8bit value from 0 to
127 (with 127 meaning silence). When converting from double, make sure to clip
the value, this also prevent integer overflow in the conversion. This fixes an
issue where a lower then -127db is reported and random level with near silent
streams (due to integer overflow).
Fixes#4068
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8012>
Convert segment to TIME format immediately instead of waiting for
_chain() to be called. This fixes converted segment never being pushed
downstream.
Fix the convert function that was copying some fields in the wrong
direction. Add fast copy if segment is already in TIME format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7977>
execute_next_action_full() logs that it removes the source when an
action returns ASYNC, but the code for that was incomplete, as it was
setting source_id to zero but not actually removing the source.
This lead to execute_next_action_full() being run continuously, only
alliviated by the default 10ms interval in the GSource from
`scenario->priv->action_execution_interval`.
This patch fixes that. As a drive-by fix it also adds locking to one
remaining unlocked usage of `priv->execute_actions_source_id`.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8014>
There were a couple strings containing \(. That is not a valid escape
sequence in Python. The escape sequence was meant for GStreamer, and as
such either the backslash should be doubled or a raw string must be
used. This patch uses the latter for readability.
Python 3.13 will print a warning when a invalid escape sequence in a
string is found.
As a drive-by fix, this patch fixes fixes whitespace issues in the file
to make the Python linter happy.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8015>
First remove validations since they will fail if there isn't a write operation.
It's valid to pass data without write operations.
Finally, it should check for hasOverride in feedback info. Nonetheless, there's
a NVIDIA bug returning always FALSE for hasOverride, that's why we currently
force it to TRUE.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7993>
At least some Mesa drivers (see llvmpipe_query_dmabuf_modifiers()) don't
initialize the provided external_only array, so some format/modifier
combinations could get incorrectly marked as only external.
Make sure we zerofill the array before passing it to
eglQueryDmaBufModifiersEXT().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6792>
* if downstream provides us with a pool that can allocate DMA buffers,
gldownload wraps it into a GL buffer pool that uses
glEGLImageTargetTexture2DOES() to import dmabuf into textures
* upstream GL elements can allocate from that pool
* gldownload unwraps DMA buffers from incoming GL buffers and passes
them downstream
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6792>
Most importantly, this ensures that UDP streams still continue to run even if
they are not linked for a while. With decodebin3 the pads will all be unlinked
unless selected, and selecting a stream at a later time would otherwise switch
to a stream with a stopped udpsrc.
Apart from that this also ensures that actual errors from handling RTP packets
between udpsrc and the source pads are not silently ignored but considered
errors like they would be for TCP/interleaved.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7946>
This fixes a possible deadlock between gst_v4l2_video_dec_change_state
and gst_v4l2_video_dec_loop on the buffer pool.
When stopping capture, the flushing state of the v4l2 capture buffer
pool gets reverted in the processing loop after it was set via
gst_v4l2_object_unlock (self->v4l2capture) (in
gst_v4l2_video_dec_change_state). As a result, gst_v4l2_video_dec_loop
does not return and consequently, gst_pad_stop_task gets stuck waiting
for the GST_PAD_STREAM_LOCK. To circumvent this, skip acquiring the
buffer pool if stopping capture.
Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7958>
It can be used to discard closed captions from the input pad if the
matching video buffer already held closed captions.
It is useful in a scenario where captions are generated for an AV
stream, but the incoming stream already has embedded captions for
some intervals, and those original captions should be preferred.
It can also be used to make sure input CC meta is always dropped,
the default behavior remains to append aggregated CC to whatever
CC meta was already present on the input video buffer
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6072>
Scenario is that there are two (or more) GstGLContext's wrapping Qt's GL
context from either multiple qml(6)glsink or qml(6)glsrc elements. Call flow is this:
1. material 1 setBuffer()
2. material 1 bind()
3. material 2 setBuffer()
4. material 2 bind()
If the call to setBuffer() reuses the same buffer as previous call, then the
qt context is not updated in the material. If however the previously used qt
context by the material had been deactivated or freed, then bind() would fail
and could result in a critical like so:
gst_gl_context_thread_add: assertion 'context->priv->active_thread == g_thread_self ()' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7970>
A pipeline always has an async bus, which involves allocating an fd pair. As
splitmuxsrc only uses the bus' sync handler, this is not required and can easily
cause splitmuxsrc to exceed the fd limit for no good reason.
The other features of GstPipeline are also not needed here, e.g. clock selection.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7952>
We only want to switch to a selection of an output collection if all streams are
present.
This was previously only done in one place (when triggering by new incoming
streams) but not when triggered by user/application.
Avoid this by moving the check to handle_stream_switch()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7941>
Some streams in the wild have empty segments at the beginning and
hlsdemux2 use to stall forever while we can handle it by processing
the following ones. The gap handling mechanism in adaptivedemux2
works properly and pushes the required gaps.
Update validate medias so the hls stream is present.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6034>
When the driver does not implement ENUM_FRMESIZE for some specific
formats, the caps limiting the sizes may endup empty, which results in
assuming the driver can scale to any sizes.
Ensure that the original size is in the caps to prevent this assumption.
This happens with Hantro drive, since it only reply to that call if the
format is postprocessed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7849>
A GST_VIDEO_FORMAT_* could be mapped to only one pair of DRM_FORMAT_*
and DRM_FORMAT_MOD_*. Until now only DRM_FORMAT_MOD_LINEAR was used.
To be able to add other modifiers add a modidier field in struct FormatMap.
Create a helper functions the allow turning a GstVideoFormat into a pair
of DRM fourcc and modifier and vis-versa.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7849>
In the case where the bufferlist is writable, send the
buffers immediately without adding to the refcount. This
allows writable buffers to maintain their writability, even
without implementing a chain_list function on the element.
Adds a test to verify this property, where a writable list
maintains refcount 1, but a readonly list increases it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7894>
We had a problem with negotiation of the framerate.
Gstreamer was querying the FRAMEINTERVALS based on the max frame size
instead of the desired frame size.
This was resulting in non-negotiated errors when trying to run with a
smaller frame size and fps higher than the max for the max image size.
Fx the max framerate for 1024x1024 RGB on CMOSIS4000 is 28.292
While for 1024x100 RGB it is 280.867
But Gstreamer would allow any framerates bigger than 28.292 no matter
the frame size used...
I have fixed it by 1st changing the CAPS query to use the minimum frame
size instead of maximum.
This however has the downside of allowing gstreamer to negotiate
framerates that are too high if the image size is bigger than the
minimum.
This is not a huge problem since our driver just CLAMPS the fps value to
the max then.
However gstreamer was not being properly notified of this change, and
would therefore report a wrong fps in the CAPS structure.
Note that the fps would be correct inside the buffer info.
Since gstreamer was reading the fps back after setting it.
It was just not being "propagated" to the CAPS structure.
I have also added a WARNING to this point so we can see if the fps that
gstreamer tries to apply was accepted or not.
And the next part of the fix was to add a framerate check after the
frame size has been established.
I did this inside the fixate_caps function of the v4l2src, which was
calling the TRY_FMT in order to check if the format was correct.
So I just added a check for the ENUM_FRAMEINTERVALS in there.
And now we get the non-negotiated again if the fps is too high for the
selected frame size.
Also added a couple of warnings so it is easy to see that this was the
cause.
See:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3037
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7850>
Instead of the libc ceil() and pow() machinery for double types, since the
library uses it for unsigned integers use a simple math function for for ceil
division and bit left shift for integer power of two.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7869>
But also don't wait for a buffer on both pads, which might take forever in case
of gaps in one of the streams.
The muxer can only advance the time if it has a timestamped buffer that can be
output, otherwise it will just busy-wait and use up a lot of CPU.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7871>
This is a custom mapping. There isn't much needed apart from that to store vp9
in mpeg-ts since the bitstream is self contained.
Since there are no official specification we don't want people to be mistaken in
believing that. Therefore that mapping is only used in the muxer if the (new)
property `enable-custom-mappings` is set to TRUE.
* The MPEG-TS Stream Type is Private Data (0x6) with the registration descriptor
set to `VP09`.
* The Access Unit are VP9 frames stored in PES packets
* As there is no emulation prevention byte in VP9 elementary stream, the can be
misdetection of PES start code. To avoid this, the start of a PES packet must
be signalled using the Payload Unit Start Indicator in the transport packet
header
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7707>
When encoding an image to mpeg2 video, with something like:
gst-launch-1.0 encodebin name=e profile=mpegpsmux:video/mpeg,mpegversion=2,systemstream=false ! \
filesink location=sample.mpg filesrc num-buffers=1 blocksize=$(stat -c%s sample.png) \
location=sample/dts.png ! pngdec ! e.
The only frame's type is set to an invalid value 0
The consequence is that mpegvideoparse sets the delta unit flag on the buffer because
it is not an I frame, then decodebin3 drops this only frame because the delta
unit flag is set and the decoder receives eos before it was able to receive any
encoded data
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7832>
Some special videos with mlv fourcc can't be recognized by
qtdemux when the subtype of the video is vide instead of
m1v, and will cause negotiation error in subsequent plugin.
So make the handle in qtdemux_video_caps. It might be better
than nothing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7855>
Variable f1 is never used, so just skip that loop for now.
The test has never actually tested actual resampling because of
that bug it seems, and the test fails if fixed to actually resample.
For now we just avoid the pointless 126*12 pipelines that were just
testing the same thing (nothing) over and over again.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7827>
Tensor can be row or col major, but it's also possible that the order by we need
to read the tensor with more than two dimension need to be described. The
reserved field in GstTensorDim is there for this purpose. If we need this we
can add GST_TENSOR_DIM_ORDER_INDEXED, and follow an index defining order for
each dimension.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6000>
GstTensor contained two fields (data, dims) that were dynamicallay allocated. For
data it's for a GstBuffer and we have pool for efficient memory management. For
dims it's a small array to store the dimension of the tensor. The dims field
can be allocated inplace by moving it at the end of the structure. This will
allow a better memory management when GstTensor is stored in an analytics meta
which will take advantage of the _clear interface for re-use.
- New api to allocate and free GstTensor
To continue to support use-cases where GstTensor is not stored in an
analytics-meta we provide gst_tensor_alloc, gst_tensor_alloc_n and
gst_tensor_free that will facilitate memory management.
- Make GstTensor a boxed type
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6000>
Adding an option to keep them no matter what.
Log files are often pretty large and keeping them around can be annoying,
usually people won't look at logs files for passing tests, and we do not
even print them out.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7700>
Only in LTC mode we introduce additional latency that is depending on only on a
property and not on the framerate, so waiting for the framerate is not necessary.
In all other modes no latency is introduced at all and the latency query can
simply be proxied.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7831>
There is no point in having an endian marker on 8 bit bayer format names since
it is just one byte. Thus remove it.
This also fixes an incompatibility with plugins bad where there is no endian
marker on 8 bit bayer format names as well.
Fixes: #3729
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7826>
The `reuse` property end up setting the SO_REUSEADDR socket option for
the UDP socket. This setting have surprising effects.
On Linux systems the man page (`socket(7)`) states:
```
SO_REUSEADDR
Indicates that the rules used in validating addresses supplied
in a bind(2) call should allow reuse of local addresses. For
AF_INET sockets this means that a socket may bind, except when
there is an active listening socket bound to the address.
```
But since UDP does not listen this ends up meaning that when an
ephemeral port is allocated (setting the `port` to `0`) the kernel is
free to reuse any other UDP port that has `SO_REUSEADDR` set.
Tests checking the likelyhood of port conflict when using multiple
`udpsrc` shows port conflicts starting to occur after ~100-300 udpsrc
with port allocation enabled. See issue #3411 for more details.
Changing the default value of a property is not a small thing we risk
breaking application that rely on the current default value. But since
the effects of having `reuse` default `TRUE` on can also have damaging
and hard-to-debug consequences, it might be worth to consider.
Having `SO_REUSEADDR` enabled for multicast, might have some use cases
but for unicast, with dynamic port allocation, it does not make sense.
When not using an multicast address we will disable port reuse if the
`port` property is set to 0 (=allocate) and warn the user that we did
so.
Closes#3411
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7841>
Combine the appsrc and appsink settings into one place and ensure that
the appsrc will output a TIME segment, to avoid incorrect segment format
criticals in some situations.
The D3D11 path was already setting the segment format correctly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7839>
The gst_dep.get_variable('libexecdir') may fail in some scenarios
(e.g. building a module alone inside an uninstalled devenv) and
it shouldn't really be reached in the first place if docs are
disabled via options.
Also to avoid confusing meson messages when cross-compiling or
doing a static build.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7818>
This commit adds a Find Module implementing the necessary logic to link
against GStreamer, while implementing some extra bits to enhance the
compatibility.
The first addition is the `mobile` target, which implements the
monolithic `gstreamer_android` library, and which here gains
compatibility with Apple's operating systems.
The second addition is the handling of the basic GStreamer libraries as
`--whole-archive` when statically linked, which was ported from the
ndk-build project in Cerbero. This is not easy to do, as CMake suffers
from several issues that impede its proper usage of pkg-config:
- It cannot differentiate between system/compiler specific libraries
e.g. `-lm`, `-ldl`, but especially `-framework Cocoa`.
- It does not support `--whole-archive` natively until 3.27
- It attempts to reorder flags blindly by separating them with spaces,
thus requiring the use of `-Wl,` wrapping or (in the case of Apple
frameworks) manual framework lookup
The third addition is the port of the Fontconfig and ca-certificates
bundling logic.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6881>
The calculated position was off. I'm not sure of the exact cause;
possibly because we're in AU-aligned byte-stream mode, which means
`transform` is true.
Replacing the math that calculates the NALU positions with code more
similar to what is already in use for `idr_pos` seems to have fixed it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7318>
We do not own any ref to queries when running them.
If we end up processing the query from the streaming thread, it means that it was
a serialized query, and the query is being waited to be processed on the sinkpad
streaming thread, thread which owns the reference.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7767>
Add missing pixel format constants, and mappings for
P010, packed variants of 420 and RGBA layouts to GStreamer
buffer formats. This fixes problems with android decoders
refusing to output raw video frames with decoders that
announce support for these common pixel formats and
only allowing the 'hardware surfaces output' path.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7743>
Previously the wrapping of the 24-bit reference time was not handled
correctly when transforming it into GstClockTime. Given the unit of 64ms
the span that could be represented by 24 bits is 12 days and depending
on the start value we could get a wrapping problem anytime within this
time frame. This turned out to be particularly problematic for the GCC
algorithm in gst-plugins-rs which tried to evict old packages based on
the "oldest" timestamp, which due to wrapping problems could be in the
future. Thus, the container managing the packets could grow without
limits for a long time thereby creating both CPU and memory problems.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7527>
Don't assume that video/x-raw caps means buffers are mappable
or can be processed by videoconvert and friends. Only plug
those converters for real system memory, and treat other
memory capsfeatures as hardware surfaces
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7741>
Some file format standards don't require mastering-display-info
and content-light-level values to be provided.
Decklink however requires the static HDR metdata for the PQ transfer
function which we may not have.
CTA-861-G mentions that in this case, 0 may provided as an 'unknown'
value which is what we use here.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7742>
* Consistently name parse functions according to their message type and
deprecate the misnamed ones,
* Add missing parse functions,
* Check for the correct message type when parsing
* Use correct field name for warning message details
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7754>
If a stream has an 'irregular' frame rate (e.g. metadata) RTCP SR
may be generated way too early, before the RTPSource has received
the first packet after Latency was configured in the pipeline.
We skip such RTPSources in the RTCP generation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7740>
This is documented as:
> you can query how many buffers are queued by reading the
> #gstqueue:current-level-buffers property. you can track changes
> by connecting to the notify::current-level-buffers signal (which
> like all signals will be emitted from the streaming thread). the same
> applies to the #gstqueue:current-level-time and
> #gstqueue:current-level-bytes properties.
... but was not implemented.
This also respects the `notify::silent` property for the notify signals
to be less intrusive.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7486>
Instead of registering the whole list of formats associated to a chroma, our
experience with GstVA tells that entry points only handles one color format per
supported chroma, and they are reflected in the static table.
This avoids exposing unsupported color formats for negotiation.
Fixes: #3914
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7708>
There is the possibility than an element/code/helper creates an identical
`GstStream` (same type and stream-id) instance instead of re-using a previous
one.
For those cases, when detecting whether a `GstStream` is already present in a
collection, we need to do more checks than just comparing the pointer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7716>
If we can't get the current caps when receiving a stream-start, that's fine,
they can/will be provided by other means at a later time.
What we definitely should not do is provide the starting caps of the chain,
which are potentially completely different from the end ones (like for example
`application/x-rtp`)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7716>
If an encoder supports multiple codecs (a bin wrapping/auto-plugging encoders)
then its src pad template caps might list the supported codecs. Without this
patch the selected parser would be the one corresponding to the first codec,
leading to caps negotiation error later on. The proposed fix is to check the
media type on the parser candidates sink pad templates according to the
requested encoded format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7670>
The diff between compared timestamps might be outside the gint range
resulting in wrong sorting results. This patch corrects that by
comparing the timestamps and then returning -1, 0 or 1 depending on the
result.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7726>
The wraparound handling code assumes that the PCR gets updated regularly for
being able to detect wraparounds. With ignore-pcr=true that was not the case and
it stayed initialized at 1h forever.
To avoid this problem, update the fake PCR whenever the PTS advanced by more
than 5s, and also detect wraparounds in these fake PCRs.
Problem can be reproduced with
$ gst-launch-1.0 videotestsrc pattern=black ! video/x-raw,framerate=1/5 ! \
x264enc speed-preset=ultrafast tune=zerolatency ! mpegtsmux ! \
tsdemux ignore-pcr=true ! fakesink
which restarts timestamps at 0 after around 26h30m.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7588>
Some servers (e.g. Axis cameras) expect the client to propose the encryption
key(s) to be used for SRTP / SRTCP. This is required to allow re-keying so
as to evade cryptanalysis. Note that the behaviour is not specified by the
RFCs. By setting the 'client-managed-mikey-mode' property to 'true', rtspsrc
acts as follows:
* For a secured profile (RTP/SAVP or RTP/SAVPF), any media in the SDP
returned by the server for which a MIKEY key management applies is
elligible for client managed mode. The MIKEY from the server is then
ignored.
* rtspsrc sends a SETUP with a MIKEY payload proposed by the user. The
payload is formed by calling the 'request-rtp-key' signal for each
elligible stream. During initialisation, 'request-rtcp-key' is also
called as usual. The keys returned by both signals should be the same
for a single stream, but the mechanism allows a different approach.
* The user can start re-keying of a stream by calling SET_PARAMETER.
The convenience signal 'set-mikey-parameter' can be used to build a
'KeyMgmt' parameter with a MIKEY payload.
* After the server accepts the new parameter, the user can call
'remove-key' and prepare for the new key(s) to be served by signals
'request-rtp-key' & 'request-rtcp-key'.
* The signals 'soft-limit' & 'hard-limit' are called when a key
reaches the limits of its utilisation.
This commit adds support for:
* client-managed MIKEY mode to srtpsrc.
* Master Key Index (MKI) parsing and encoding to GstMIKEYMessage.
* re-keying using the signals 'set-mikey-parameter' & 'remove-key' and
then by serving the new key via 'request-rtp-key' & 'request-rtcp-key'.
* 'soft-limit' & 'hard-limit' signals, similar to those provided by srtpdec.
See also:
* https://www.rfc-editor.org/rfc/rfc3830
* https://www.rfc-editor.org/rfc/rfc4567
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7587>
When force-live is TRUE, aggregator will correctly change its state with
NO_PREROLL, but unless something upstream is live did not previously set
live to TRUE on the latency query.
Fix this by or'ing force_live into the result.
Also improve debug
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7718>
Clients that already gotten a signal for synced clock, may rely on
getting the same when marked as corrupted to take appropriate action. So
send clock signal indicating no sync at identified corrupted state.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7664>
This allows the stream to drive the buffers submitted to the display server.
If the application does not receive frame events for a period of time due to
minimization or tty switch for example, instead of waiting to process and
then catching up when frame events resume, the stream will resume instantly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7691>
There is no requirement for a base DRM format to be supported by libgstvideo
in order to be uploaded to. Don't limite to DRM fourcc that have a libgstvideo
format mapping. This notably enabled AFBC support, which uses an opaque based
format that does not have a linear definition. This also adds R8/RG88 and
simimlar other formats that are not yet mapped in libgstvideo.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7689>
When the stream resolution change it is needed to negotiate
a new pools and to update the caps.
Resolution change could occurs on a new sequence or a new
picture so move resolution change detection code in a common
function.
For memory allocation reasons, only allows resolution change
on non keyframe if the driver support remove buffer feature.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7684>
We must drain the pending output picture so that subclass can renegotiate
the caps. Not doing so while still renegotiating would mean that the
subclass would have to do an allocation query before pushing the caps.
Pushing the caps now without this would also not work since these caps
won't match the pending buffers format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7684>
Add helpers function to call VIDIOC_REMOVE_BUFS ioctl.
If the driver support this feature buffers are removed from the queue when:
- the pool when is detached from the decoded.
- the pool is released.
- allocation failed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7684>
Use VIDIOC_CREATE_BUFS ioctl to create buffers instead of VIDIOC_REQBUFS
because it allows to create buffers also while streaming.
To prepare the introduction of VIDIOC_REMOVE_BUFFERS create
the buffers one per one instead of a range of them. This way
it can, in the futur, fill the holes.
gst_v4l2_decoder_request_buffers() is stil used to remove all
the buffers of the queue.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7684>
When a datachannel within a session is removed after proper close,
reference to the error_ignore_bin elements of the datachannel
appsrc/appsink were left in webrtcbin.
This caused the bin-objects to be left and not freed until the whole
webrtc session was terminated. Among other things that includes a thread
from the appsrc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7675>
We want to ensure the stream-collection is present on the pad (as a sticky
event) before we expose the pad.
This is more reliable since it will ensure it is present before any other event
is pushed through.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7609>
- Add mtd_meta_clear to allow specific analytics-meta to handle their clear
operation specific to their type.
- Clear mtd's attached when analytic-meta is freed. When the buffer where
analytics-meta is attached is not from a buffer pool
gst_analytics_relation_meta_clear will not be called unless we explicitly call
it in _free. This important otherwise _mtd_clear are not called and lead to
leak if embedded mtd's allocated memory
- Un-ref in transform if it's a copy
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6026>
FLUSH_STOP is meant to clear the flushing state of pads and elements
downstream, not to process data. Hence, a FLUSH_STOP should not
propagate sticky events. This is also consistent with how flushes are a
special case for probes.
Currently this is almost always the case, since a FLUSH_STOP is
__usually__ preceded by a FLUSH_START, and events (sticky or not) are
discarded while a pad has the FLUSHING flag active (set by FLUSH_START).
However, it is currently assumed that a FLUSH_STOP not preceded by a
FLUSH_START is correct behavior, and this will occur while autoplugging
pipelines are constructed. This leaves us with an unhandled edge case!
This patch explicitly disables sending sticky events when pushing a
FLUSH_STOP, instead of relying on the flushing flag of the pad, which
will break in the edge case of a FLUSH_STOP not preceded by a
FLUSH_START.
If sticky events are propagated in response to a FLUSH_STOP, the
flushing thread can end up deadlocked in blocking code of a downstream
pad, such as a blocking probe. Instead, those events should be
propagated from the streaming thread of the pad when handling a
non-flushing synchronized event or buffer.
This fixes a deadlock found in WebKit with playbin3 when seeks occur
before preroll, where the seeking thread ended up stuck in the blocking
probe of playsink:
https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/1367
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7632>
H.266 NAL unit header syntax [1] is similar to H.265 NAL unit header syntax[2]:
```
H.265 H.266
+---------------+---------------+ +---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| NALType | LayerId | TID | |F|U| LayerId | NALType | TID |
+-------------+-----------+-----+ +-------------+-----------------+
Where
* F: `forbidden_zero_bit`: f(1)
* U: `nuh_reserved_zero_bit`: u(1) only H.266
* LayerId: `nuh_layer_id`: u(6)
* NALType: `nal_unit_type`: u(6) in H.265 and u(5) in H.266
* TID: `nuh_temporal_id_plus1`: u(3)
```
NAL unit types have different values:
| NALType | H.265 | H.266 |
|----------|------------------------------------|---------------------------|
| VPS | HEVC_NAL_VPS(32) | VVC_VPS_NUT(14) |
| SPS | HEVC_NAL_SPS(33) | VVC_SPS_NUT(15) |
| PPS | HEVC_NAL_PPS(34) | VVC_PPS_NUT(16) |
| IRAP | BLA_W_LP(19)..HEVC_NAL_CRA_NUT(21) | IDR_W_RADL(7)..CRA_NUT(9) |
Implementation of `h266_video_type_find` is based on `h265_video_type_find` with
next differences:
- NAL unit header syntax for H.265 and H.266
- Diff NAL unit types values
- Avoid checking nuh_layer_id is zero. H.266 conformance test suite[3] contains examples with more than one layer.
This typefind was tested with H.266 conformance test suite [3]. Also, with the help of fluster[4],
with H.264 and H.265 conformance test suites to avoid regresions. Pending test vectors to fix:
- 8b422_H_Sony_4
- DEBLOCKING_E_Ericsson_3
[1] https://www.itu.int/rec/T-REC-H.266
[2] https://www.itu.int/rec/T-REC-H.265
[3] https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/draft_conformance/draft6/
[4] https://github.com/fluendo/fluster/
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7339>
I wanted to check if an element had the SINK flag and realized it was
not displayed in gst-inspect.
The clock flags were already reported as part of the "clocking
capabilities" info but best to have them explicitly listed here as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7641>
In my tests with the new GCC 14 compiler for Cerbero, I got the
following error:
> In file included from include/directxmath/DirectXMath.h:2275,
> from ../gst-libs/gst/d3d11/gstd3d11converter.cpp:46:
> include/directxmath/DirectXMathMatrix.inl: In function 'bool
> DirectX::XMMatrixDecompose(XMVECTOR*, XMVECTOR*, XMVECTOR*, FXMMATRIX)':
> include/directxmath/DirectXMathMatrix.inl:1161:16:
> error: variable 'aa' set but not used [-Werror=unused-but-set-variable]
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7658>
Check and generate remote reception statistics from the info stored on
internal sources, as they are stored there when running against newer rtpbin
since MR !7424
This fixes cases where statistics are incomplete when
peers send RR reports from a single remote ssrc, which GStreamer does
when bundling is enabled and other RTP stacks may too.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7425>
In some cases, decodebin3 will send us incomplete caps (not containing
codec_data), and then a GAP event, which will force a negotiation.
This segfaults due to a null pointer deref because self->input_state
is NULL.
The only possible fix is to avoid negotiating when we get incomplete
caps (to avoid re-negotiationg immediately afterwards, which isn't
supported by some muxers), but also set as much input state as
possible so that a renegotiation triggered by a GAP event can complete
successfully.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7634>
Move RB info from receiver reports into the internal source that the RR
are about, and deprecate (but retain) the old mapping where each
external source has only a single RB entry in the rtp statistics.
The old method is broken if a remote peer uses a single ssrc to send
receiver reports for more than one of our internal sources, other
as multiple RB in a single packet, or alternate RB in different reports.
In each case only the most recent entry was kept, overwriting data for
other internal sources.
In multicast scenarios each internal source may receive multiple
receiver reports from different peers. To support that, all received
RR's are now stored into a hash table indexed by the sender's SSRC,
and all RRs are placed into an array when generating statistics, so
that the information from all peers is retrievable.
The current deficient behaviour (adding RB info into non-internal RTPSources) is
deprecated but kept in order to be backward compatible, and retained
that way in the generated statistics structure.
Refs
[1] https://tools.ietf.org/html/rfc3550#section-6.4.1
Based on a patch by Fede Claramonte <fclaramonte@twilio.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7424>
This commit fixes two issues:
- The event must be posted *after* calling stop, otherwise a race condition can occur and the app never stops
- isFinishedLaunching and applicationDidFinishLaunching are not always synchronized, causing sometimes
a deadlock on the g_cond_wait never catching the g_cond_signal
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7593>
In order to ensure all initial events (stream-start, caps, ..) are present on
pads that we expose, those various sticky events are propagated (from parsebin
to multiqueue output, from multiqueue output to exposed pads).
The problem was that the "hack" in `urisourcebin` to inform downstream elements
that the stream is parsed data and a collection will be present was only done in
one place : a probe on the output of parsebin ... but the stream-start could
potentially have already been propagated to the output pads before that.
In order to fix that, we make sure any pending sticky stream-start event is
updated before being propagated.
Fixes#3788
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7598>
This new LCEVC encoder plugin is meant to implement all LCEVC encoder elements.
For now, it only implements the LCEVC H264 encoder (lcevch264enc) element. This
element essentially encodes raw video frames using a specific EIL plugin, and
outputs H264 frames with LCEVC data. Depending on the encoder properties, the
LCEVC data can be either part of the video stream as SEI NAL Units, or attached
to buffers as GstMeta.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7330>
