Having an unlimited input queue is very bad if the
encoder can't run at real-time. Eventually it will
consume all RAM. I don't really see any reason to
have more than 1 outstanding encoded frame, so
remove the queue and limit things to 1 pending frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2499>
Use gap events to update the next_time of a queue the same
as buffers or segment events. Fixes problems where a group
consisting only of sparse streams primarily driven by
gap events would stall with a full multiqueue because
unlinked streams in the group were not being woken to
push data.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/879>
There was a race when going to PAUSED while pushing a buffer to the
pipeline process (where we weren't even cancelling anything).
This rework base all the cancellation around the GCancellable
"cancelled" signal trying to ensure that the streaming thread will not
block once a cancel operation happens.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2504>
During the output process, if there are multiple frames in a TU (i.e. multi-spatial
layers case), only one frame with the highest spatial layer id should be selected
according to av1 spec. The highest spatial layer id is obtained from idc value of
the operating point.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2475>
Commit bc09d8cc changed gstmpdparser to put the entire
<ContentProtection> element in the "value" field, so that DRMs
other than PlayReady could make use of the data inside this
element.
However, the data in the "value" field does not include any
XML namespace declarations that are used within the element. This
causes problems for a namespace aware XML parser that wants to
make use of this data.
This commit modifies the way the XML is converted to a string
so that XML namespaces are preserved in the output.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2487>
Some closedcaption elements like sccenc except input buffers
to have timecode metas. The original use case is to serialize
closed captions extracted from a video stream, in that case
ccextractor copies the video time code metas to the closed
caption buffers, but no such mechanism exists when creating
a CC stream ex nihilo.
Remedy that by having timecodestamper accept closedcaption
input caps, as long as they have a framerate.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2490>
It seems "GST_VAAPI_PLUGIN_BASE_SRC_PAD_CAN_DMABUF (decode)" will
return false even if this platform support the mem_type dma buffer.
And media-driver will return GST_VAAPI_BUFFER_MEMORY_TYPE_DMA_BUF2
on Gen12(such as TGL).
Without this patch, The command such as:
gst-launch-1.0 videotestsrc num-buffers=100 ! video/x-raw, format=I420 ! \
x264enc ! h264parse ! vaapih264dec ! video/x-raw\(memory:DMABuf\) ! fakesink
will return not-negotiated.
Signed-off-by: Zhang Yuankun <yuankunx.zhang@intel.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/437>
GstWebRTCSCTPTransport is now made into into an abstract base class
that only contains property specifications matching the
RTCSctpTransport interface of the W3C WebRTC specification, see
https://w3c.github.io/webrtc-pc/#rtcsctptransport-interface. This
class is put into the WebRTC library to expose it for applications and
to allow for generation of bindings for non-dynamic languages using
GObject introspection.
The actual implementation is moved to the subclass WebRTCSCTPTransport
located in the WebRTC plugin.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2214>
Being able to access the SCTP Transport object from the application
means the application can access the associated DTLS Transport object
and its ICE Transport object. This means we can observe the ICE state
also for a data-channel-only session. The collated
ice-connection-state on webrtcbin only includes the ICE Transport
objects that resides on the RTP transceivers (which is exactly how it
is specified in
https://w3c.github.io/webrtc-pc/#rtciceconnectionstate-enum).
For the consent freshness functionality (RFC 7675) to work the ICE
state must be accessible and consequently the SCTP transport must be
accessible for enabling consent freshness checking for a
data-channel-only session.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2214>
Prevent cluttering up the rtpsession, and keeping things localized.
Also write TWCC-seqnums for *all* streams in the session if configured by
caps.
A while back WebRTC was not doing TWCC for audio, basically breaking the
whole idea of a "transport-wide seqnuencenumber" applying for all bundled
streams. However, they have since fixed this, and now it no longers
makes sense to be able to single out certain payloadtypes for
use with TWCC, rather just including them all.
This also makes using RTX, RED, FEC etc much simpler, as it will apply
to them all as they enter the rtpsession.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/927>
