By setting the earliest time to timestamp + 2 * diff there would be a difference
of 1 * diff between the current clock time and the earliest time the element
would let through in the future. If e.g. a frame is arriving 30s late at the
sink, then not just all frames up to that point would be dropped but also 30s of
frames after the current clock time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7459>
This makes sure that if upstream has different latencies that we're still
outputting buffers with increasining timestamps across the different streams
unless buffers are arriving after the latency deadline.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7500>
Adding prefer-stream-ordered-alloc property to GstCudaContext.
If stream ordered allocation buffer pool option is not configured
and this property is enabled, buffer pool will enable the stream
ordered allocation. Otherwise it will follow default behavior.
If GST_CUDA_ENABLE_STREAM_ORDERED_ALLOC env is set,
default behavior is enabling the stream ordered allocation.
Otherwise sync alloc/free method will be used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7427>
Default CUDA memory allocation will cause implicit global
synchronization. This stream ordered allocation can avoid it
since memory allocation and free operations are asynchronous
and executed in the associated cuda stream context
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7427>
While transforming the internals of waylandsink into a library, the
context type name was accidentally changed, causing an ABI break. Change
it back to its original (as used by the libgstgl), and add support for
the misnamed version as a backward compatibility measure.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7482>
If the UVC gadget announces multiple formats in the descriptors the uvcsink
doesn't select the actual format but let's the UVC hosts select the format.
If the GStreamer pipeline is started before a UVC host selected the format,
upstream decides on a format until the UVC host has decided. In this case, the
current format needs to be set based on the caps from the caps event to be able
to detect if the format selection by the UVC host requires a format change on
the GStreamer pipeline.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7473>
The uvcsink may be put into the READY state to start listening for UVC requests.
Therefore, the UVC host may set a streaming format before the GStreamer pipeline
is started and the uvcsink received a caps event. In this case, prev_caps will
be NULL.
If the EVENT_CAPS has not been received, skip the check if the format needs to
be changed, since the sink will be started with the format selected by the UVC
host, anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7473>
Adding a property to control the number of in-flight GPU commands
(default is unlimited). Note that actual maximum number is defined
in d3d12device's direct command queue object which is 32 now,
thus total number of scheduled GPU commands cannot exceed 32.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7444>
Sometimes under certain loads, VT can error out with kVTVideoEncoderMalfunctionErr or kVTVideoEncoderNotAvailableNowErr.
These have been reported to happen more often than usual if CopyProperty/SetProperty() is used close to the encode call.
Both can be worked around by restarting the encoding session.
These errors can be returned either directly from VTCompressionSessionEncodeFrame() or later in the encoding callback.
This patch handles both scenarios the same way - a session restart is be attempted on the next encode_frame() call.
If the error is returned immediately by the encode call, it's possible that some correct frames will still be given to
the output callback, but for simplicity (+ because I wasn't able to verify this scenario) let's just discard those.
In addition, this commit also simplifies the beach/drop logic in enqueue_buffer.
Related bug reports in other projects:
http://www.openradar.me/45889262https://github.com/aws/amazon-chime-sdk-ios/issues/170#issuecomment-741908622
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7173>
If state is changing from playing to paused, and rate is reset to 1
which causes seek position is valid, current code will do seek for
streams that are not seekable. So need to check whether stream is
seekable before seeking.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7441>
If the pending remote description has an invalid BUNDLE group _parse_bundle()
triggers early return from _create_answer_task(), before ret has been
initialized, so it needs to be checked before attempting to call
gst_sdp_message_copy().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7423>
webrtcsrc first creates recvonly transceivers with codec-preferences
and expects that after applying a remote description, the
previously created transceivers are used rather than having new
transceivers created.
When pairing webrtcsink + webrtcsrc, the offer sdp from webrtcsink has a media
section with sendonly direction. In !7156, which was implemented following
RFC9429 Section 5.10, we only reuse a unassociated transceiver when applying a
remote description if the media is sendrecv or recvonly, and that caused creation
of new transceivers when applying a remote offer in webrtcsrc, thus losing
information from codec preferences like the RTP extension headers in the
previously created transceivers.
Since the change in !7156 broke existing code from webrtcsrc, relax the condition
for reusing unassociated transceivers and add a test to document this behavior which
wasn't covered by any tests before.
Fixes#3753.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7417>
