In media/mtransport/third_party/nICEr/src/stun/addrs.c:
stun_getifaddrs() is used on all non-WIN32 targets. It extracts from the
kernel an array describing network interfaces (I think). These are written
into its out-parameter nr_local_addr addrs[] and the number of entries is
written to int *count.
There is a path through the main loop in stun_getifaddrs() which can cause a
nr_local_addr record to be returned with its .interface.type field being
uninitialized, but which nevertheless is later used. It also looks as if the
.interface.estimated_speed field is not initialised.
This commit zero-initialises the entire output array before writing anything
into it, to avoid such problems, on all targets.
Differential Revision: https://phabricator.services.mozilla.com/D58822
--HG--
extra : moz-landing-system : lando
This removes various unused `#include "nsAutoPtr.h"` in `xpcom/`. Additionally
adds a few includes to the media stack.
Differential Revision: https://phabricator.services.mozilla.com/D58282
--HG--
extra : moz-landing-system : lando
Client of WebrtcMediaDataEncoder unregisters callback before calling
Shutdown(). When a pending encode promise gets resolved after that,
it will cause null pointer error.
Differential Revision: https://phabricator.services.mozilla.com/D55760
--HG--
extra : moz-landing-system : lando
UBSan was complaining about taking `&password_[0]` when the vector had zero capacity, because its STL's implementation of `operator[]` used a reference in an intermediate step, and putting null into a reference is prohibited.
While I'm here, I dropped the `const_cast`, since the callee was changed to accept `const UCHAR*` years ago.
Differential Revision: https://phabricator.services.mozilla.com/D58643
--HG--
extra : moz-landing-system : lando
We don't need to start transmitting until the transceiver asks us to. Doing
this early leads to creating and tearing down an audio send stream
unnecessarily, generating extra RTCP byes. These changes make the behaviour
consistent with the VideoConduit version.
Differential Revision: https://phabricator.services.mozilla.com/D57864
--HG--
extra : moz-landing-system : lando
This consolidates the shutdown code and ensures that an RTCP bye is sent
as part of tearing down a PeerConnection.
Differential Revision: https://phabricator.services.mozilla.com/D57861
--HG--
extra : moz-landing-system : lando
With tracks in different MTGs we risk of having thread races if we stop and start immediatelly. Previously, stoping and starting was happenign to the same MTG so this problem did not exist. This change wires a promise in the `MediaTrack::RemoveListener` method and perform the start when that step has been completed.
Differential Revision: https://phabricator.services.mozilla.com/D57947
--HG--
extra : moz-landing-system : lando
In `MediaPipelineTransmit::SetTrack()` the provided `MediaStreamTrack` connects to the existing send-track. This step crashes if the two tracks belong to different MTGs. With this change, when the two tracks belong to different MTGs, the existing send-track is stopped and deleted and a new send-track is created in the same MTG with the provided `MediaStreamTrack`.
Differential Revision: https://phabricator.services.mozilla.com/D57627
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
- Convert to a StunAddrRequestState enum so there is now a pending state,
rather than just done/not done. This is to make sure we don't have
multiple stun addrs requests in flight at the same time.
- Reset the stun addrs in PeerConnectionMedia from PeerConnectionImpl when
PeerConnectionImpl::SetSignalingState_m detects ICE restart in an offer.
- GatherIfReady will now request new stun addrs if none are available.
Differential Revision: https://phabricator.services.mozilla.com/D55883
--HG--
extra : moz-landing-system : lando
There are known bugs with recv_timeout which may explain the crashes we're
seeing in Bug 1603349. This patch switches to using try_recv which returns
immediately if no data is available. This thread already has timeouts set in
the UDP socket reads and writes, so the timeout with the receive channel
should not be necessary.
Differential Revision: https://phabricator.services.mozilla.com/D57448
--HG--
extra : moz-landing-system : lando
We should only add a hostname to mSignaledAddresses if it is not obfuscated.
Prior to Bug 1567201 this was handled by an early exit in
MediaTransportHandlerSTS::AddIceCandidate if the address was obfuscated.
With the changes in Bug 1567201, that early exit went away and we're now adding
all addresses to mSignaledAddresses which breaks hiding prflx and srflx
addresses. Unfortunately, this is not something that easily unit testable.
Differential Revision: https://phabricator.services.mozilla.com/D57140
--HG--
extra : moz-landing-system : lando
Bug 1598923 - P1 - Remove use of description API and use format in SDP rust to C bindings;r?drno
Bug 1598923 - P2 - Add pref to select strictness of SDP parsing success;r?drno
Bug 1598923 - P3 - Update to WEBRTC-SDP 0.3.2;r?drno
Bug 1598923 - P4 - update to WEBRTC-SDP 0.3.3;r?mjf
Bug 1598923 - P5 - Adapt channel handling to WEBRTC-SDP changes;r?mjf
Differential Revision: https://phabricator.services.mozilla.com/D55211
--HG--
extra : moz-landing-system : lando
The STS thread dispatches SyncRunnables to main thread. There are two cases of
blocking affected here:
- SyncRunnables from main to STS:
Can cause a deadlock.
- PR_Sleep on the main thread:
Effectively sleeps STS too, if STS dispatches a SyncRunnable to main during
main's sleep.
This patch gets rid of both of these.
Depends on D57001
Differential Revision: https://phabricator.services.mozilla.com/D57003
--HG--
extra : moz-landing-system : lando
Before this patch, if a send audio MediaStreamTrack ended, we ended up not
sending anything over the network. If replaceTrack() at that point replaced the
ended track with a live one, we'd start sending data again, but the rtp stream
would continue from where the previous track ended.
Having a gap in audio like that would confuse a receiver's *video* jitter
buffer, because it's trying to sync to an audio track that just had a massive
amount of "jitter" (it can't tell the difference).
This patch fixes this by adding a track layer in MediaPipelineTransmit that
remains active for as long as the MediaPipeline is active. Thus if the send
audio MediaStreamTrack ends, we continue sending silence over the network, which
the receiver can understand. If later replaced, the receiver sees real audio
instead of silence and continues gracefully.
Differential Revision: https://phabricator.services.mozilla.com/D56619
--HG--
extra : moz-landing-system : lando
Before this patch, if a send audio MediaStreamTrack ended, we ended up not
sending anything over the network. If replaceTrack() at that point replaced the
ended track with a live one, we'd start sending data again, but the rtp stream
would continue from where the previous track ended.
Having a gap in audio like that would confuse a receiver's *video* jitter
buffer, because it's trying to sync to an audio track that just had a massive
amount of "jitter" (it can't tell the difference).
This patch fixes this by adding a track layer in MediaPipelineTransmit that
remains active for as long as the MediaPipeline is active. Thus if the send
audio MediaStreamTrack ends, we continue sending silence over the network, which
the receiver can understand. If later replaced, the receiver sees real audio
instead of silence and continues gracefully.
Differential Revision: https://phabricator.services.mozilla.com/D56619
--HG--
extra : moz-landing-system : lando
We don't currently set a write timeout on the udp socket which could cause
write calls to block indefinitely. It is possible that this is blocking
long enough to cause the shutdown hangs seen in Bug 1601992.
This also bumps the number of times we retry failed queries from 2 to 3 to
account for the increased likelihood of not sending a query or answer.
Differential Revision: https://phabricator.services.mozilla.com/D56536
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
The changed-files are updated by running `sh update.sh <upstream-path>`
with moz-libsoundtouch.patch applied.
Differential Revision: https://phabricator.services.mozilla.com/D49029
--HG--
extra : moz-landing-system : lando
Correct the format of the diff for AAFilter.cpp so the update-script can
work.
Differential Revision: https://phabricator.services.mozilla.com/D49028
--HG--
extra : moz-landing-system : lando
This happens very frequently in rr runs, and may explain some
intermittents we've seen in automation.
Differential Revision: https://phabricator.services.mozilla.com/D54520
--HG--
extra : moz-landing-system : lando
Removes calls to the win32k API.
Replaces hardware and event timers with waitable timers.
Removes handling various task objects through the thread message queue.
Removes ProcessQueuedMessages, CancelTimers functions.
Adds event handle for stopping the TaskQueue thread.
Adds ReplyHandler class as an in between for TaskQueue objects to post tasks to each other without worrying if the other TaskQueue remains valid.
Adds rtc::CriticalSection's for timer_tasks_.
Removes ThreadState scoped class.
Differential Revision: https://phabricator.services.mozilla.com/D43480
--HG--
extra : moz-landing-system : lando
This moves the telemetry and preferences out into their own files and restores the parse result telemetery.
Differential Revision: https://phabricator.services.mozilla.com/D52749
--HG--
extra : moz-landing-system : lando
