In order to simplify caps negotiations for clients and, notably, be more
compatible with va* decoders.
Crucially this allows clients to know ahead of time whether buffers will
actually be DMABufs.
Similar to GstVaBaseDec we only announce system memory caps if the peer
has ANY caps. Further more, and again like va decoders, we fail in
`decide_allocation()` if DMA_DRM caps are used without VideoMeta.
Apart from buggy peers this can happen e.g. when a peer with ANY caps
is used in combination with caps filters.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6376>
Most importantly rely on video info helpers instead of manual parsing
of caps, which will allow us to use additional helpers in the future.
While on it, tighen the check for supported formats - failing that
indicates a bug in caps negotiation - and make some style changes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6376>
This ensures we don't create filter caps that are not supported by the
individual codec implementations, as well as that the resulting caps
have the required fields so they can be turned into a GstVideoFormat.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6376>
This is the maximum amount supported by aacenc. 8-channel output fully works.
16-channel also encodes fine, but codec-utils isn't able to parse its channel config,
so output level will not be shown in caps. For that to work, GASpecificConfig parsing
needs to be implemented. It's not a critical issue and can be worked on at a later date.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6375>
Memory from gst_adapter_map() could live shorter than the GstMemory that the GstBuffer wraps around it, which in lucky
cases 'just' caused a re-use of the same memory for multiple (potentially still in use!) input buffers, but could easily
end up pointing to an already-freed memory.
Manifested when an AudioToolbox encoder kept getting silence inserted in seemingly random circumstances, turned out
to be the memory being re-used by GStreamer at the same time that the AT API was processing it...
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6339>
This fixes a crash in `gst_va_h264_enc_class_init` and `gst_va_h265_enc_class_init`
(and probably also in gst_va_av1_enc_class_init) when calling
`g_object_class_install_properties (object_class, n_props, properties);`
When rate_control_type is 0, the following code is executed in :
```
} else {
n_props--;
properties[PROP_RATE_CONTROL] = NULL;
}
```
n_props has initially a value of N_PROPERTIES but PROP_RATE_CONTROL
is not the last element in the array, so it's making
g_object_class_install_properties fail to iterate over the
properties array.
This applies the same fix to gstvah264enc.c, gstvah265enc.c and
gstvaav1enc.c.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6344>
None of the GL allocators actually offer a generic alloc() implementation. As a
side effect, they cannot be offered as they don't work with generic video
buffer pool.
Our specialized buffer pool can be dropped by tee or alphacombine as sharing the
same buffer pool over two branch is not supported by the pool API.
Fixes#3372
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6350>
Do not chain up to parent's GstBufferPool::start() which will do
preallocation. We don't want it to be preallocated
since there are various cases where negotiated downstream buffer pool is
not used at all (e.g., zero-copy decoding, IPC elements).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6345>
On systems using UsrMerge (like openSUSE or Fedora), /lib64 is
a symlink to /usr/lib64. So dladdr is returning the path to
the gstreamer library in /lib64 in priv_gst_get_relocated_libgstreamer.
Later gst_plugin_loader_spawn tries to build the path to the
gst-plugin-scanner helper from /lib64 and ends up trying to use
/lib64/../libexec/gstreamer-1.0/gst-plugin-scanner which doesn't exist.
By canonicalizing the path with a call to realpath, gst-plugin-scanner
is found correctly under
/usr/lib64/../libexec/gstreamer-1.0/gst-plugin-scanner
Similar change applied to gstreamer/libs/gst/net/gstptpclock.c
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6343>
This matches autoplug in other places such as decodebin, otherwise we
will pick "randomly" based on the order in which plugins are
registered, which is mostly dependent on the order in which readdir()
returns items.
So let's make it predictable.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6342>
This will mimic the playbin2 behaviour, which sets the "next" entry to be
NULL.
The biggest impact this has is that when going back to READY the current play
entry will be discarded (instead of being kept around for when you go back to
PAUSED/PLAYING).
Fixes#3371
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6338>
Since commit 4d86f994, when setting an RTSP media both shared and
reusable, streaming cannot be restarted after the first time all the
clients disconnect. That happens because the sockets (unlike
addresses) of GstRTSPStream are not cleared in
gst_rtsp_stream_leave_bin, and on restart sockets and addresses are
not allocated in gst_rtsp_stream_allocate_udp_sockets, and then the
check in create_sender_part fails. Fix this by clearing sockets in
gst_rtsp_stream_leave_bin.
Fixesgstreamer/gst-rtsp-server#113
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6334>
find_slot_for_stream_id() will return a slot which has the request stream-id as
active_stream *or* pending_stream (i.e. the slot on which that stream is
currently being outputted or will be outputted).
When figuring out which slot to use (if any) we want to consider stream-id
which *will* appear on a given slot which isn't outputting anything yet the same
way as if we didn't find a slot yet.
Fixes races when doing intensive state changes
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6332>
With the new copy_opaque system, the corresponding frame is stored in the
picture opaque ref.
This also handles the case where the "regular" opaque might be empty in the
case of "DECODE_ONLY" frames, since it that field is set in `get_buffer2()`
which might not be called for those frames
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6331>
When we're doing a state change from PLAYING to NULL, first we invoke
gst_rtspsrc_loop_send_cmd_and_wait (..., CMD_CLOSE, ...) during
PAUSED_TO_READY which will schedule a TEARDOWN to happen async on the
task thread.
The task thread will call gst_rtspsrc_close(), which will send the
TEARDOWN and once it's complete, it will call gst_rtspsrc_cleanup()
without taking any locks, which frees src->streams.
At the same time however, the state change in the app thread will
progress further and in READY_TO_NULL it will call gst_rtspsrc_stop()
which calls gst_rtspsrc_close() a second time, which accesses
src->streams (without a lock again), which leads to simultaneous
access of src->streams, and a segfault.
So the state change and the cleanup are racing, but they almost always
complete sequentially. Either the cleanup sets src->streams to NULL or
_stop() completes first. Very rarely, _stop() can start while
src->streams is being freed in a for loop. That causes the segfault.
This is unlocked access is unfixable with more locking, it just leads
to deadlocks. This pattern has been observed in rtspsrc a lot: state
changes and cleanup in the element are unfixably racy, and that
foundational issue is being addressed separately via a rewrite.
The bandage fix here is to prevent gst_rtspsrc_stop() from accessing
src->streams after it has already been freed by setting src->state to
INVALID.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6330>
And also re-timestamp them with the current buffer's PTS.
Not doing so keeps the timestamps of event packets as
GST_CLOCK_TIME_NONE or the timestamp of the previous buffer, both of
which are bogus.
Making sure that (especially) the first packet has a valid timestamp
allows putting e.g. the NTP timestamp RTP header extension on it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6298>
Parse the speed and scale in the server's response
*before* the range, so that the range start/stop
are swapped (or not swapped) correctly based
on the server's actual chosen values. Otherwise,
the old rate from the segment is used - what the
last seek asked for, but not necessarily what
the server chooses.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6295>
In the situation where playback starts from a keyframe before
the target playback segment, then the first buffers will be
outside the configured segment and gst_segment_to_stream_time()
will return GST_CLOCK_TIME_NONE unconditionally.
If drop-out-of-segment is false, the RTP buffers will not be
dropped, but will be sent witout ONVIF extension timestamps
and given GST_CLOCK_TIME_NONE timestamps on the receiver.
Instead, use gst_segment_to_stream_time_full() to extrapolate
stream time outside the segment so that such buffers still
get assigned their correct timestamps on the receiver.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6295>
Don't accidentally include the stuffing byte (if present)
into the bottom field size. It should only be included in the
total segment length.
Fixes problems with FFmpeg not rendering the subtitles
with a stuffing byte, giving a "Invalid object location!" error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6277>
Cocoa version of glwindow only checks the preferred size upon window creation. glimagesink sets the size right before
calling gst_gl_window_show(), which might be way after the window is created in some cases. If the size was set too
late, glimagesink on macOS would remain 320x240 unless manually resized.
This change makes sure to resize the existing window when _show() is called.
Curiously, this has always been an issue, but went from manifesting every once in a while to being almost completely
broken once old event loop workarounds were removed and gst_macos_main() was introduced.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6276>
Don't use g_return_val_if_fail() to catch the
open-ended segment or empty segment cases in
gst_segment_to_running_time_full()
g_return_val_if_fail() is for programmer errors,
and can be compiled out with a flag.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6275>
Gets being released memory back to queue even if allocator is flushing
in order to count the number of outstanding memory objects.
Also, clear queue if there's no outstanding memory object and
allocator is flushing
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6240>
Making it possible to properly handle compositors that have those
properties as doubles and handle antialiasing.
Internally we were handling those values as doubles in framepositioner,
so expose new properties so user can set values as doubles also.
This changes the GESFramePositionMeta API but we are still on time for 1.24
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6241>
The `G_DECLARE_FINAL_TYPE` macro does not need to be terminated with a
semicolon and the extra semicolon breaks building e.g. libcamera with
clang because `-Wextra-semi` is used which produces the following
error in conjunction with `-Werror`:
```
gstreamer-1.0/gst/allocators/gstdrmdumb.h:61:43: error: extra ';' outside
of a function is incompatible with C++98 [-Werror,-Wc++98-compat-extra-semi]
61 | GST, DRM_DUMB_ALLOCATOR, GstAllocator);
| ^
1 error generated.
```
Fix this by removing the extra semicolon
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6239>
Syncrhonizing buffer commits to the streaming thread can lead to
dropped frames when frame callbacks are not processed before the
next frame is ready for rendering. Depending on the drift between
the wayland compositor and buffer source timings, this can lead to
periods of significant frame drop, especially when the media frame
rate is close to the display frame rate.
Cache buffers in the streaming thread and peform commits on the
display thread to eliminate the buffer commit racing.
The implementation is the same for both waylandsink and gtkwaylandsink,
so move it to the common wayland library under gst-lib.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6133>
Add synchonized versions of wl_display_sync() and wl_callback_destroy()
that will ensure that to callbacks can be managed in a thread safe way
on the display queue even when they are dispatched from a separate
thread.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6133>
Unprepare method posts WM_GST_D3D11_DESTROY_INTERNAL_WINDOW
command to the window queue, and from that moment considers
internal_hwnd to be released, and so it sets it to null.
The problem is that it's possible that right at that moment
the window thread might be already processing some other
command, or just another command might be already in the queue.
On practice we met a crash when WM_PAINT got processed in between
(unprepare already finished and WM_GST_D3D11_DESTROY_INTERNAL_WINDOW
was not handled yet)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6187>
In the case where the queue shrinks due to a property change and the queue
becomes full, we would set the waiting_del flag, which would prevent posting the
100% buffering message on the bus. Since the pipeline is not aware of the new
buffering value, in the common case where the pipeline is paused during
buffering, it would never resume.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6165>
Remove the percent_changed check to determine whether a buffering message should
be posted. The check on the last posted buffering value is sufficient, and the
removal doesn't introduce additional complexity.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6165>
If input height and parsed one are identical, do not consider it as interlaced
Fixing below pipeline:
gst-launch-1.0 videotestsrc ! video/x-raw,format=I420,width=640,height=10 \
! jpegenc ! jpegparse ! jpegdec ! videoconvert ! autovideosink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6181>
When dealing with demuxers which aren't streams-aware, we need to handle the
old-school "stream replacement" dance from `parsebin` and hide that in such a
way that output pads are re-used (if compatible).
By analyzing the collection posted by parsebin, we can:
* Identify whether some output slots are no longer used (because the stream they
currently handle is not present in the collection)
* Decide if some upcoming streams could re-use the existing slot
This supports both buffering and non-buffering modes.
Fixes#1651
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6201>
When the conversion is only caps feature from memory:VAMemory to system memory,
it's possible to optimize by doing a pseudo pass-through since the va-backed
buffers are the same for system memory buffers.
This change will also mitigates #2940
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6174>
If the allocation query received from downstream doesn't handle GstVideoMeta but
it requests memory:DMABuf caps feature, it's incomplete, so we rather reject the
negotiation.
Both in base decoder, base transform and compositor.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6155>
