If both data channels become ready simultaneously, then the two integer
read-add-update cycles can execute concurrently and only ever increment
once instead of the required twice. Use an atomic add instead.
It is very possible for badly behaving signalling or peers to send
us ICE candidates before we receive an SDP. While we had consideration
for that on the first set SDP, subsequent SDP's could result in
misconfigured ICE transports. Expand the previous code to also take
into account reconfigurations.
Limitations:
- No transport changes at all (ICE, DTLS)
- Codec changes are untested and probably don't work
- Stream removal doesn't remove transports (i.e. non-bundled transports
will stay around until webrtcbin is shutdown)
- Unified Plan SDP only. No Plan-B support.
Currently, if one was to set -Dhls-crypto to either libgcrypt or openssl
instead of auto, the following lines would fail because hls_crypto_dep is not
yet set:
if not hls_crypto_dep.found() and ['auto', 'libgcrypt'].contains(hls_crypto)
if not hls_crypto_dep.found() and ['auto', 'openssl'].contains(hls_crypto)
Instead, change "if not hls_crypto_dep.found()" to "if not have_hls_crypto"
which fixes the error.
Use a timeout to limit that amount of time we wait after the compositor
for the initial configure event. Compositor are support to emit a
configure event before any wl_buffer can be attached. The problem is
that Weston strongly enforce this, while gnome-shell simply does not
emit such an event.
When buffer is used by compositor, we don't need attach it and hold one
more reference. Just check used_by_compositor, just return if it is true.
Assert error log is not need, this is normal behavior.
... when it has not yet been connected to.
Also, a condition variable is not a semaphore, so a lock/wait/unlock
sequence is inherently racy without any state checking. So switch to
a different lock and check the intended state.
Some GIR annotations were incorrect or even missing. The former isn't
good for bindings, while the latter is especially annoying for signal
handlers, as that means your arguments will get the wrong names in the
rendered documentation.
GST_VIDEO_BUFFER_FLAG_INTERLACED and GST_VIDEO_BUFFER_FLAG_TFF
flags are needed when processing SCTE 20 closed captions for an interlaced
stream, when we need to convert back to analog, in which case we need to match
the caption to the top or bottom field
... if (x265 version >= 1.9) requirement is satisfied.
The SEI messages were supported since x265 version 1.8
but there was API change from version 1.9
(contentLightLevelInfo was renamed to maxCLL and maxFALL)
This change makes it possible to create more than just 5 webrtc
data channels. The maximum number of data channels is exactly
DEFAULT_NUMBER_OF_SCTP_STREAMS / 2, therefore the limit is now
512.
Use proper API to flush libass events when we do
a flushing seek, and also do it in FLUSH_STOP
rather than FLUSH_START, so we can be sure
streaming has stopped.
Fixes seeking back in time.
Something seems to have changed in libass that
renders the old manual way of flushing events
ineffective and libass then seems to ignore
timestamps that are older than the ones last
seen then if we do it the old way.
Fixes#916
