Getting the JNI calls here to work requires a good amount of webrtc.org
machinery. It might be worth setting that up the next time we do an upstream
merge, but for now, it is a lot simpler to just remove the affected code,
given that we are not interested in collecting this data anyway.
Differential Revision: https://phabricator.services.mozilla.com/D61860
--HG--
extra : moz-landing-system : lando
Although originally part of webrtc.org, this code has subsequently been
removed by upstream. Moving it to under dom/media should make it clearer that
this is code that we are maintaining and simplify future upstream merges.
Differential Revision: https://phabricator.services.mozilla.com/D61850
--HG--
rename : media/webrtc/trunk/webrtc/modules/video_capture/android/device_info_android.cc => dom/media/systemservices/android_video_capture/device_info_android.cc
rename : media/webrtc/trunk/webrtc/modules/video_capture/android/device_info_android.h => dom/media/systemservices/android_video_capture/device_info_android.h
rename : media/webrtc/trunk/webrtc/modules/video_capture/android/java/src/org/webrtc/videoengine/CaptureCapabilityAndroid.java => dom/media/systemservices/android_video_capture/java/src/org/webrtc/videoengine/CaptureCapabilityAndroid.java
rename : media/webrtc/trunk/webrtc/modules/video_capture/android/java/src/org/webrtc/videoengine/VideoCaptureAndroid.java => dom/media/systemservices/android_video_capture/java/src/org/webrtc/videoengine/VideoCaptureAndroid.java
rename : media/webrtc/trunk/webrtc/modules/video_capture/android/java/src/org/webrtc/videoengine/VideoCaptureDeviceInfoAndroid.java => dom/media/systemservices/android_video_capture/java/src/org/webrtc/videoengine/VideoCaptureDeviceInfoAndroid.java
rename : media/webrtc/trunk/webrtc/modules/video_capture/android/video_capture_android.cc => dom/media/systemservices/android_video_capture/video_capture_android.cc
rename : media/webrtc/trunk/webrtc/modules/video_capture/android/video_capture_android.h => dom/media/systemservices/android_video_capture/video_capture_android.h
extra : moz-landing-system : lando
This is an import of the Android camera code as of upstream revision
26762d0425ffd15af9ddc3ae669373668827ea00 (Dec 20, 2019). This takes just the
files required to build the camera related classes.
Differential Revision: https://phabricator.services.mozilla.com/D61849
--HG--
extra : moz-landing-system : lando
Now that cbindgen.toml is a required file, update-rust.sh must be
updated to avoid clobbering it.
Differential Revision: https://phabricator.services.mozilla.com/D60971
--HG--
extra : moz-landing-system : lando
Holding a RefPtr to this in OnRtcpBye should keep the VideoConduit alive until
the callback completes. If this is not happening, it is likely that we're
racing with the destructor on the other thread. Clearing the callback early
will prevent this. This should not affect the VideoConduit because in that case
the callback is directly part of the receive stream, not attached to a channel.
Differential Revision: https://phabricator.services.mozilla.com/D60658
--HG--
extra : moz-landing-system : lando
In order to support the update to move args when invoking callbacks we:
- Convert anything that was using WrapRunnable with `nsAutoPtr` to `UniquePtr`
- Convert anything that was using a non-const ref as a param to either a
const ref or a by-val copy
Addtionally we convert the remaining `nsAutoPtr` usage to `UniquePtr`.
Differential Revision: https://phabricator.services.mozilla.com/D59961
--HG--
extra : moz-landing-system : lando
In order to support `UniquePtr` as an arg type for `WrapRunnable` as well as
avoid unnecessary copies in the future we need to switch to moving args when
invoking a runnable.
This updates `WrapRunnables` so that they move their args when running and
adds/updates some tests. To accomplish this `std::apply` is swapped in for our
bespoke implementation and `std::tuple` is used to hold the args. We then
`std::move` the args when `Run` is called. We also needed to support an r-value
`Class` param for the runnable method on a bound object versions could work
with `UniquePtr` as the holder class.
Differential Revision: https://phabricator.services.mozilla.com/D59960
--HG--
extra : moz-landing-system : lando
Holding a RefPtr to this in OnRtcpBye should keep the VideoConduit alive until
the callback completes. If this is not happening, it is likely that we're
racing with the destructor on the other thread. Clearing the callback early
will prevent this. This should not affect the VideoConduit because in that case
the callback is directly part of the receive stream, not attached to a channel.
Differential Revision: https://phabricator.services.mozilla.com/D60658
--HG--
extra : moz-landing-system : lando
`disable-assert.patch` is nor needed because the change has been merged upstream.
`revert-optimization.patch` is not needed because we want to undo the revert since this import attemptts to fix the crash.
Differential Revision: https://phabricator.services.mozilla.com/D60517
--HG--
extra : moz-landing-system : lando
`disable-assert.patch` is nor needed because the change has been merged upstream.
`revert-optimization.patch` is not needed because we want to undo the revert since this import attemptts to fix the crash.
Differential Revision: https://phabricator.services.mozilla.com/D60517
--HG--
extra : moz-landing-system : lando
In `MediaPipelineTransmit::SetTrack()` when a track of different MTG is replaced, the transmission is stopped and restarted asynchronously. This can create a problem if a new stop has arrived in the meantime. The transmission should not be restarted in that case.
This change adds a boolean, to check when an asynchronous start is expected and ignores it if not needed.
Differential Revision: https://phabricator.services.mozilla.com/D59750
--HG--
extra : moz-landing-system : lando
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--HG--
extra : moz-landing-system : lando
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
Currently we register mDNS hostnames when we gather the local interfaces. By
waiting until StartIceChecks is called, it is less likely that we will end up
starting the mdns_service for a site which is not using WebRTC for
communication. This is more efficient, and avoids surprises like triggering
the Windows Firewall dialog for sites which are using WebRTC to gather local
IP addresses.
Differential Revision: https://phabricator.services.mozilla.com/D59765
--HG--
extra : moz-landing-system : lando
The original values of 10ms were chosen arbitrarily. Decreasing the values may
help prevent shutdown hangs like those seen in Bug 1601992.
Differential Revision: https://phabricator.services.mozilla.com/D58844
--HG--
extra : moz-landing-system : lando
We did this for the VideoConduit in Bug 1404992, but not for the AudioConduit
because of the ongoing webrtc.org upstream merge.
Differential Revision: https://phabricator.services.mozilla.com/D59424
--HG--
extra : moz-landing-system : lando
We've already decided when to remove support for DTLS 1.0, so I don't think we
need to track DTLS version anymore. The DTLS and SRTP cipher probes are
intended to track cipher usage so we can remove less secure ciphers over time.
I had a look at the telemetry for these and I don't think there's a clear case
for removal at the moment, so we should renew these for now.
Differential Revision: https://phabricator.services.mozilla.com/D58835
--HG--
extra : moz-landing-system : lando
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
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
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
PhysicalSocketServer isn't currently used by Mozilla's WebRTC
integration, but just in case, let's make sure that this array index is
bounds-checked in actual use, not just in debug builds (which tend to
never see realistic test conditions).
Differential Revision: https://phabricator.services.mozilla.com/D52745
--HG--
extra : moz-landing-system : lando
This adds a whitelist of domains for which mDNS hostname obfuscation is
disabled. The implementation is an updated version of the old screensharing
whitelist code.
Differential Revision: https://phabricator.services.mozilla.com/D52012
--HG--
extra : moz-landing-system : lando
This adds a whitelist of domains for which mDNS hostname obfuscation is
disabled. The implementation is an updated version of the old screensharing
whitelist code.
Differential Revision: https://phabricator.services.mozilla.com/D52012
--HG--
extra : moz-landing-system : lando
The mDNS code makes use of the StunAddrsRequest which does not exist when
we are running with e10s disabled. If e10s is disabled, PeerConnectionMedia
will not be in the content process, and we can disable hostname obfuscation
in that case.
Differential Revision: https://phabricator.services.mozilla.com/D51986
--HG--
extra : moz-landing-system : lando
This swaps things around so that received tracks in peer connections have a
content principal instead of a null principal initially.
This puts an extra requirement on us to not output any frames under the content
principal after ALPN has been negotiated with requested privacy, but before this
private principal has been signaled to the MediaPipelines. The private principal
is signaled from the STS thread, via the main thread, whereas media is consumed
directly by MediaPipelines after being received on the STS thread.
This patch adds an extra signaling path directly from the STS thread that tells
MediaPipelines to make their PrincipalHandle private, and to ignore any data
until the private PrincipalHandle is set. It also moves the responsibility of
updating the principal of the received MediaStreamTracks from TransceiverImpl
to MediaPipeline, so it's all in the same path.
This lets all MediaStream and MediaStreamTrack APIs consume received tracks
directly after getting exposed to JS without errors. In case privacy is later
requested, consumers that have already been set up must handle this on the fly.
(They do, in specs and impls)
Differential Revision: https://phabricator.services.mozilla.com/D48947
--HG--
extra : moz-landing-system : lando
nsISerialEventTarget is more semantically accurate for these uses, as the
dispatched runnables cannot run in parallel. It also allows us to use
InvokeAsync in future patches, as that function only takes nsISerialEventTarget.
Differential Revision: https://phabricator.services.mozilla.com/D49262
--HG--
extra : moz-landing-system : lando
This patch fixes two things:
1) A potential threading issue in setting and reading the PrincipalHandle for
MediaPipelineReceiveVideo.
2) Plumbs the PrincipalHandle down to the receiving MediaPipelines right from
the start. It hasn't been necessary in the past as initially the principal
handed to a track's constructor is trusted, but it's good form and will help
clarify the situation for the next patch which switches the initial
principal from always-private to mostly-non-private. In most cases this
principal does no longer get updated after the track's been created, so it
helps to have a PrincipalHandle that matches the track's principal.
Differential Revision: https://phabricator.services.mozilla.com/D48946
--HG--
extra : moz-landing-system : lando
This swaps things around so that received tracks in peer connections have a
content principal instead of a null principal initially.
This puts an extra requirement on us to not output any frames under the content
principal after ALPN has been negotiated with requested privacy, but before this
private principal has been signaled to the MediaPipelines. The private principal
is signaled from the STS thread, via the main thread, whereas media is consumed
directly by MediaPipelines after being received on the STS thread.
This patch adds an extra signaling path directly from the STS thread that tells
MediaPipelines to make their PrincipalHandle private, and to ignore any data
until the private PrincipalHandle is set. It also moves the responsibility of
updating the principal of the received MediaStreamTracks from TransceiverImpl
to MediaPipeline, so it's all in the same path.
This lets all MediaStream and MediaStreamTrack APIs consume received tracks
directly after getting exposed to JS without errors. In case privacy is later
requested, consumers that have already been set up must handle this on the fly.
(They do, in specs and impls)
Differential Revision: https://phabricator.services.mozilla.com/D48947
--HG--
extra : moz-landing-system : lando
nsISerialEventTarget is more semantically accurate for these uses, as the
dispatched runnables cannot run in parallel. It also allows us to use
InvokeAsync in future patches, as that function only takes nsISerialEventTarget.
Differential Revision: https://phabricator.services.mozilla.com/D49262
--HG--
extra : moz-landing-system : lando
This patch fixes two things:
1) A potential threading issue in setting and reading the PrincipalHandle for
MediaPipelineReceiveVideo.
2) Plumbs the PrincipalHandle down to the receiving MediaPipelines right from
the start. It hasn't been necessary in the past as initially the principal
handed to a track's constructor is trusted, but it's good form and will help
clarify the situation for the next patch which switches the initial
principal from always-private to mostly-non-private. In most cases this
principal does no longer get updated after the track's been created, so it
helps to have a PrincipalHandle that matches the track's principal.
Differential Revision: https://phabricator.services.mozilla.com/D48946
--HG--
extra : moz-landing-system : lando
Changes:
- update sections of `generate_sources_mozbuild.py` and `cmakeparser.py` to be python3 compatible
- change import of `urlparse` to be python3 compatible
Depends on D51414
Differential Revision: https://phabricator.services.mozilla.com/D51692
--HG--
extra : moz-landing-system : lando
The current coreaudio-sys in gecko is a custom 0.2.2 version that used
to avoid the cross-compiling issue mentioned in bug 1569003. The issue
has been fixed in the coreaudio-sys 0.2.3, so we should follow the
upstream instead of using a custom version. As a result, the
coreaudio-sys would generate API bindings based on the MacOS SDK defined
in the build settings.
Differential Revision: https://phabricator.services.mozilla.com/D50531
--HG--
extra : moz-landing-system : lando
The number of channels is available in mAudioFrame in GetAudioFrame so
there is no reason to calculate it after the fact in MediaPipeline.
Differential Revision: https://phabricator.services.mozilla.com/D50934
--HG--
extra : moz-landing-system : lando
The use of select() was leading to crashes when the file descriptor value was
larger than FD_SETSIZE. Recent versions of glibc have checks in the FD_CLR(),
FD_SET() and FD_ISSET() macros that will abort() the program instead of doing
an out-of-bounds access. poll() doesn't have limitations on the file
descriptor values and provides behavior that is otherwise identical to
select() thus solving the problem.
Differential Revision: https://phabricator.services.mozilla.com/D50798
--HG--
extra : moz-landing-system : lando
Revert the coreaudio-sys dependency changed in bug 1589514, which causes
a trouble when compiling with sccache
Differential Revision: https://phabricator.services.mozilla.com/D50529
--HG--
extra : moz-landing-system : lando
This ICE candidate telemetry has not been used in a long time and in
addition requires special handling by the telemetry code. It is best
removed.
Differential Revision: https://phabricator.services.mozilla.com/D50656
--HG--
extra : moz-landing-system : lando
This updates libdav1d to commit 5595102721d3c298d7cee64e64878486a3b8bdad.
Differential Revision: https://phabricator.services.mozilla.com/D50205
--HG--
rename : third_party/dav1d/snap/snapcraft.yaml => third_party/dav1d/package/snap/snapcraft.yaml
extra : moz-landing-system : lando
Pick commits:
92e2e11 - minor style fix
5163960 - Update authors
fdb0b1d - Make utf8_from_cfstringref work with empty CFStringRef (#20)
a39bf5f - Remove a fixed issue
Differential Revision: https://phabricator.services.mozilla.com/D50002
--HG--
extra : moz-landing-system : lando
The code for handling backwards wraps left shifts num_wrap_ - 1. If
num_wrap_ is zero, this results in a left shift of a negative value which
is undefined behaviour. This modifies the code to avoid the shift at the cost
of an extra multiplication.
Differential Revision: https://phabricator.services.mozilla.com/D49609
--HG--
extra : moz-landing-system : lando
This adds checks for invalid and duplicated rtp extension ids to
JsepSessionImpl. Since the version of webrtc.org we're using does not support
two byte extension ids, ids must be between 1 and 14 inclusive. Duplicated
extension ids are also disallowed by RFC 8285. Passing an invalid extension id
into the webrtc.org code will trigger a release assertion and a browser crash.
Differential Revision: https://phabricator.services.mozilla.com/D48689
--HG--
extra : moz-landing-system : lando
These have already been fixed upstream. The upstream comment was: "Negative
overflow is permitted here, because this is auto-regressive filters, and the
state for each batch run is stored in the "negative" positions of the output
vector."
Differential Revision: https://phabricator.services.mozilla.com/D48884
--HG--
extra : moz-landing-system : lando
Simon Giesecke
Boris Zbarsky
Brindusan Cristian
Dan Minor
Jon Bauman
Byron Campen [:bwc]
Matthew Gregan
Nico Grunbaum
Bogdan Tara
Dorel Luca
Jan-Ivar Bruaroey
Coroiu Cristina
Eric Rahm
Ciure Andrei
Cosmin Sabou
Alex Chronopoulos
Noemi Erli
Emilio Cobos Álvarez
Sylvestre Ledru
Aaron Klotz
Alex Henrie
shindli
Ryan VanderMeulen
Julian Seward
John Lin
David Major
Nathan Froyd
Chris Peterson
Michael Froman
Jeff Walden
Andreas Pehrson
Mike Hommey
Gabriele Svelto
Chun-Min Chang
june wilde
Jed Davis
Landry Breuil
Edwin Takahashi
Dzmitry Malyshau
Nils Ohlmeier [:drno]
Arthur Iakab
Paul Adenot
Mihai Alexandru Michis
Jeff Gilbert
Jan Beich