When waylandsink is used on some other thread than the main wayland
client thread, the waylandsink implementation is vulnerable to a
condition related to registry and surface events which handled in
seperated event queue.
The race that may happen is that after a proxy is created, but
before the queue is set, events meant to be emitted via the yet to
set queue may already have been queued on the wrong queue.
Wayland 1.11 introduced new API that allows creating a proxy
wrappper which can help to avoid this race condition.
This is for testing race condition with multi-thread wayland client
environment. The race condition will be resolved with wayland proxy
wrapper API when handling event queue.
vps/sps/pps in codec_data shouldn't be considered as inband data.
Otherwise, h26{4,5}parse never insert them to nal when transform
(packetized to byte-stream) use case
We will add more profiles in the sink caps of msdkh265enc, so let
msdkh265enc re-add the sink pad template. Note this change doesn't
impact any capability
Fixes the time calculations when dealing with a slaved clock (as
will occur with more than one decklink video sink), when performing
flushing seeks causing stalls in the output timeline, pausing.
Tighten up the calculations by relying solely on the internal time
(from the internal clock) for determining when to schedule display
frames instead attempting to track pause lengths from the external
clock and converting to internal time. This results in a much easier
offset calculation for choosing the output time and ensures that the
clock is always advancing when we need it to.
This is fixup to the 'monotonically increasing output timestamps' goal
in: bf849e9a69
It depends on the framerate how many cc_data byte pairs are allowed per
frame, and the framerate is also needed for converting into the CDP or
MCC format as the framerate is part of the header metadata.
The wpe element is used to produce a video texture representing a web page
rendered off-screen by WPE. This element can be used to overlay HTML on top of
another video stream for instance.
The latter is going away in libfdk-aac 2.0.0. Instead, MPEG-style output
is always non-interleaved and WAV-style output is always interleaved.
Earlier libfdk-aac also defaults interleaving accordingly.
Since our reordering looks at the associated PCE indices instead of the
actual channel order, we're agnostic to the mapping.
For https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/825
Similar change as the on I did in h264parse. We want to process SEI
recovery point as keyframe so muxers will mark them as seek points and
decoders will be able to start decoding from them rather than waiting
for an IDR.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/790
The spec states that "recovery point SEI message assists a decoder in
determining when the decoding process will produce acceptable
pictures for display after the decoder initiates random access or after the
encoder indicates a broken link in the coded video sequence."
Mark those as keyframes so muxers will mark them as seek points and
decoders will be able to start decoding from them rather than waiting
for an IDR.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/790
