The timestamp/PTS alone is meaningless without the segment and usually
applications care about the running-time or stream-time.
This also keeps the messages in sync with the spectrum and level
elements.
Header data must be forwarded to downstream, but if demux does not finish
to finding type (e.g., ts, mp4 and etc), this header data can be cleared
by _stream_clear_pending_data(). Moreover, although demux finish downloading
header data, still it has fragment date to be downloaded, fragment sequence
shouldn't be advanced yet at that moment.
https://bugzilla.gnome.org/show_bug.cgi?id=776928
Including gl.h from WPEThreadedView.h leads to GST_LEVEL_DEFAULT detected as
redefined. The proposed fix is to include config.h from the CPP implementation
file and disable gl.h inclusion in the header, by using forward declarations.
1. The spec indicates that the notification should occur near the end of
'setting the description' processing
2. The current location with the drop of the lock could cause the 'check
if negotiation is needed' logic to execute and become confused about
the state of the webrtcbin's current local descriptions.
In the bad case, the following assertions could be hit:
g_assert (trans->mline < gst_sdp_message_medias_len (webrtc->current_local_description->sdp));
g_assert (trans->mline < gst_sdp_message_medias_len (webrtc->current_remote_description->sdp));
Moving the signalling state change later in the set description task
means that checking for a renegotiation will early abort as the
signalling state is not STABLE before the session description and
transceivers have been updated.
The start of each segment is relative to the Period start, minus
the presentation time offset.
As specified in section 5.3.9.6 of the MPEG DASH specification:
The value of the @t attribute minus the value of the
@presentationTimeOffset specifies the MPD start time of
the first Segment in the series.
dashdemux was not taking account of presentationTimeOffset and in
some methods was not taking into account the Period start time.
This commit modifies the segment->start value to always be
relative to the MPD start time (zero for VOD,
availabilityStartTime for live streams). This makes all uses of
the segment list consistent.
Fixes#841
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.
