In gst_video_info_dma_drm_to_caps() the caps are newly created, so there's no
need for make it writable. In gst_video_info_dma_drm_from_caps() a copy of the
caps is done, which implies a gst_caps_make_writable().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4195>
This allow allocating memory from any DRM driver that supports this
method. It additionally allow exporting DMABuf. This allocator depends
on libdrm and will be stubbed if the dependency is missing. This is derived
from kmssink dumb allocator.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3801>
These parameters are not actually `out` parameters but must
be allocated and zero-initialized by the calling function.
Marking them as `out caller-allocates` will cause memory
corruptions when calling these APIs from e.g., Python code.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4051>
Do not store cached EGL images in GstMemory QData. Instead, use a
per-DmabufUpload GHashTable to store cache entries with a weak
reference to the GstMemory.
This allows two glupload elements on separate tee branches to have
their own EGL image cache. For this pipeline:
gst-launch-1.0 v4l2src ! tee name=t \
t. ! queue ! glupload ! fakesink
t. ! queue ! glupload ! fakesink
this gets rid of the occasional critical error message:
GStreamer-CRITICAL **: 08:26:33.194: gst_mini_object_unref: assertion 'GST_MINI_OBJECT_REFCOUNT_VALUE (mini_object) > 0' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3880>
If we have caps then we can only set exactly those caps, if we have no
caps yet then negotiating anything is not very meaningful because the
caps are defined by the application and not downstream.
Avoids, among other things, an unnecessary allocation query and spurious
useless caps being set before the first buffer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3757>
We create a new context in `gst_gl_context_create_thread()` and then
activate it on the current thread. Thereafter we assume that the
current thread continues to be the active thread for that context and
call `gst_gl_context_fill_info()` which asserts that the current
thread is the active thread.
However, if at the same time a different thread calls
`send_message_async()`, it will call into
`gst_gl_window_cocoa_send_message_async()` which will schedule the
message to be invoked using GCD. That anonymous function will also
call `gst_gl_context_activate()`, which creates a race, which can lead
to:
```
gst_gl_context_fill_info: assertion 'context->priv->active_thread == g_thread_self ()' failed
```
Fix it by using `gst_gl_context_thread_add()` to invoke `fill_info()`
on the context.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3732>
This should fix pipelines such as this one to work as expected
... ! opusenc ! capsfilter caps='audio/x-opus,
channels=1; audio/x-opus, channels=2' ! ...
The expectation is that the encoder will propose the first structure
before the second one to the source.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3673>
gst-launch-1.0 audiotestsrc ! udpsink host=127.0.0.1
gst-launch-1.0 udpsrc ! audioconvert ! autoaudiosink
would crash with a floating point exception when clipping the input
buffer owing to a division by zero because no caps event was received.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3469>
Currently, when rtspsrc property add-reference-timestamp-metadata=true,
a downstream rtph264depay element will attach multiple copies of the
same GstReferenceTimestampMeta to the depayloaded media buffers. This
can have signficant performance impacts further downstream in a pipeline
like the following:
rtspsrc add-reference-timestamp-metadata=true ! rtph264depay ! h264parse ! ... ! rtph264pay ! ...
For example, if there are 10 packet buffers for a frame of RTP H.264
video, each of those packet buffers will contain the same reference
timestamp meta. The rtph264depay element will then attach all 10
metadata to the depayloaded frame. And then later when we payload the
frame buffer again for proxying, we now have 10 more buffers each with
10 instance of the same metadata. Allocating/deallocating 100+ instances
of metadata @ 30fps for multiple streams has a pretty large performance
impact.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1578
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3431>
The tile width in pixel is not always available. Notably for
8L128 10bit format, the tile is 8x128 bytes, and the pixel
format is fully packed. That means that the tile contains at
least 6 pixels per line, but it also hold some bits of the
pixel from the same line on the previous or next tile.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3424>
In current tile representation, only tiles with power of two
width and height in bytes are supported. This limitation
prevents adding more complex tiles formats.
In this patch, we deprecate tile_ws and tile_hs from GstVideoFormatInfo and
replace if with an array of GstVideoTileInfo. Each plane tiles are then
described with their pixels width/height, line stride and total size.
The helper gst_video_format_info_get_tile_sizes() that depends on the
deprecated API is also being removed. This can simply be removed as it wasn't
in any stable release yet.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3424>
Setting force_live lets aggregator behave as if it had at least one of
its sinks connected to a live source, which should let us get rid of the
fake live test source hack that is probably present in dozens of
applications by now.
+ Expose API for subclasses to set and get force_live
+ Expose force-live properties in GstVideoAggregator and GstAudioAggregator
+ Adds a simple test
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3008>
