Enable the NSS workaround introduced in bug 1619102, for DTLS 1.3 WebRTC clients.
Differential Revision: https://phabricator.services.mozilla.com/D66094
--HG--
extra : moz-landing-system : lando
Failing to drop frames if they are cropped to zero width and height leads to
the crash seen in Bug 1521169. We get a call to CreateEncoderStreams
requesting streams with zero width and height at which point it is too late
to do anything, because the webrtc.org code making the call always expects
CreateEncoderStreams to always return at least one stream, and it can't
handle streams with zero width or height.
Depends on D65799
Differential Revision: https://phabricator.services.mozilla.com/D65800
--HG--
extra : moz-landing-system : lando
Also fix AARCH64 build to be neon optimised where available, this leads to a 72% improvement in decoding speed.
Differential Revision: https://phabricator.services.mozilla.com/D64706
--HG--
extra : moz-landing-system : lando
Updating to libvpx 1.8.2 removes one of the structures used for configuring
flexibleMode in the webrtc.org vp9 encoder code. Upstream commit
be71a1ee08c9ee56ba0f92955ea946556ae6593e removes the broken code and at the
same time disables flexibleMode. It remained disabled until commit
76be29555d50f5ec9b5bba1f14588e940e81fd4d landed, three months later. During
that time, a large number of VP9 screensharing fixes were made. It is not
practical to cherrypick all of those changes, so this commit disables
flexibleMode pending the next upstream webrtc.org merge.
This is a partial cherry pick of be71a1ee08c9ee56ba0f92955ea946556ae6593e.
Differential Revision: https://phabricator.services.mozilla.com/D63925
--HG--
extra : moz-landing-system : lando
This makes the following changes:
* Change update.py to use Python 3.
* Have update.py remove some unused portions of the upstream library.
* Update local patches to apply against libvpx 1.8.2.
* Remove local patches that are no longer necessary.
* Update vs build configurations in generate_sources_mozbuild.sh.
* Remove the #define for stdint from VPXDecoder.h.
* Disable AVX512 support
* Make sure float_control_word.asm is included in win64 builds
Differential Revision: https://phabricator.services.mozilla.com/D63919
--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
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
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
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
