JSEP transceivers were previously held in a vector, in the order that they were
created. However, these could be removed, which meant that the indexing was not
stable. Under most circumstances this did not matter, however there was a
wrinkle with implicit rollback in repeated sRD. Re-applying a remote offer that
had created a transceiver would destroy that transceiver, and create a new one
to replace it. However, JS was not informed, because to PeerConnectionImpl it
looked like nothing had changed. Now, transceivers are indexed in a stable way,
which allows this bug to be fixed, and makes things a little less confusing.
Differential Revision: https://phabricator.services.mozilla.com/D70400
JSEP transceivers were previously held in a vector, in the order that they were
created. However, these could be removed, which meant that the indexing was not
stable. Under most circumstances this did not matter, however there was a
wrinkle with implicit rollback in repeated sRD. Re-applying a remote offer that
had created a transceiver would destroy that transceiver, and create a new one
to replace it. However, JS was not informed, because to PeerConnectionImpl it
looked like nothing had changed. Now, transceivers are indexed in a stable way,
which allows this bug to be fixed, and makes things a little less confusing.
Differential Revision: https://phabricator.services.mozilla.com/D70400
If we're shutting down and mSocketThread is no longer accepting work,
this dispatch can fail. As far as I can see, fully fixing this would
require changes to nsIThread in order to allow checking whether the
thread is shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D71964
If we're shutting down and mSocketThread is no longer accepting work,
this dispatch can fail. As far as I can see, fully fixing this would
require changes to nsIThread in order to allow checking whether the
thread is shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D71964
With transport-cc enabled, we get feedback calls into AudioSendStream occuring
on the sts thread. Since AudioSendStream is constructed on the main thread,
this trips up the worker_thread_checker_ checks. The functions that are called
end up doing their work using AudioCodingModuleImpl::ModifyEncoder, which
takes a lock, so it should be safe to remove these assertions.
We've had to do similar things to ChannelProxy in the past to get stats
working from the sts thread. ChannelProxy has been removed upstream, but we
should consider changing our use of AudioSendStream with the next libwebrtc
update so that is always called from the same thread.
Differential Revision: https://phabricator.services.mozilla.com/D72157
If we're shutting down and mSocketThread is no longer accepting work,
this dispatch can fail. As far as I can see, fully fixing this would
require changes to nsIThread in order to allow checking whether the
thread is shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D71964
Pick commits:
9caa5b1 - Only print the filename when logging (#581)
8a4170a - sun: Line continuation character not needed
9696902 - sun: POLL_TIMEOUT is no longer used
159fb99 - sun: Add my email address to the copyright header.
e3b409f - sun: Refactoring: reduce duplication in stream structure.
36aa8b1 - sun: Make the purpose of some variables clearer.
1654468 - sun: Update header inclusion.
38ef439 - sun: Convert floats to LINEAR32 instead of LINEAR16
4dbacae - Remove test for registering device changed callback twice
7f94e27 - Force Rust builds to always rerun cargo.
3e23b25 - Remove TODO, we've done all of those, or they don't apply anymore
Differential Revision: https://phabricator.services.mozilla.com/D70546
--HG--
extra : moz-landing-system : lando
In rare cases, the random number generator can fail to initialize when
generating a v4 UUID, causing a panic and crash. This adds code to catch that
panic and return a nil (all zeros) UUID instead. Using a nil UUID seems better
from a user privacy perspective than failing to obfuscate the host address and
leaking it when it is expected to be hidden.
Longer term, we might want to switch over to using nsIUUIDGenerator, but that
would require changes to how the socket process is initialized.
Differential Revision: https://phabricator.services.mozilla.com/D70172
--HG--
extra : moz-landing-system : lando
Emptiness of values should be checked using the `empty` method, and not
by comparing the size to 0. Fix such case in the code of
ClearKeyDecryptionManager.cpp module.
Differential Revision: https://phabricator.services.mozilla.com/D70206
--HG--
extra : moz-landing-system : lando
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Differential Revision: https://phabricator.services.mozilla.com/D67631
--HG--
extra : moz-landing-system : lando
This patch makes nsIDNSByTypeRecord extend nsIDNSRecord, but implementations
will safely forward the nsIDNSRecord methods to `nullptr`, meaning they will
throw an error when called.
Consumers should try to QI the nsIDNSRecord to nsIDNSByTypeRecord (or any
future types) and use that.
Differential Revision: https://phabricator.services.mozilla.com/D69326
--HG--
extra : moz-landing-system : lando
TRACE_AUDIO_CALLBACK() and TRACE_AUDIO_CALLBACK_COMMENT(aFmt, ...) log to a hardcoded thread id number. This creates confusion when more than one MTG is running because logs from different threads are depicted to the same thread line and overlapping each other. Those logging commands have been removed and the TRACE* command is used that it logs per thread-id.
Differential Revision: https://phabricator.services.mozilla.com/D69031
--HG--
extra : moz-landing-system : lando
There is no need to use the Git repository, its only change compared to 0.1.6
is that some random tidbit has been fixed in the README file.
Depends on D69805
Differential Revision: https://phabricator.services.mozilla.com/D69806
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
This change includes support to negotiate the transport-wide-cc RTP extension
needed to enable sender side bandwidth estimation in WebRTC. When this
extension is supported in both sides during the Offer/Answer negotiation the
transport_cc mode is enabled in the WebRTC engine so that this mode is used
instead of the legacy receiver-side (REMB based) mechanism.
The change is inspired on this fork by medooze team:
https://github.com/medooze/gecko-dev/pull/2/files
Co-authored-by: ggarber <gustavogb@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D68734
--HG--
extra : moz-landing-system : lando
Also update the update-rust.sh script in a couple ways:
- Stop copying the source for mp4parse_fallible into the tree; use crates.io
- Include submodules in mp4parse-rust checkout; needed for tests
- Exclude unnecessary build.rs from mp4parse_fallible, it was causing problems
- Update mp4rust_capi/Cargo.toml patch to exclude cdylib. It's only necessary for test_ffi and causes build problems otherwise
Differential Revision: https://phabricator.services.mozilla.com/D68139
--HG--
extra : moz-landing-system : lando
This essentially implements the "queue a task" step required by the spec, which
ensures that if JS checks stats multiple times without relinquishing the event
loop, it will see the same thing each time.
Differential Revision: https://phabricator.services.mozilla.com/D64468
--HG--
extra : moz-landing-system : lando
Primarily, this removes code that was compensating for inconsistencies between webrtc.org's timestamps, and JS timestamps. Also, this removes a few bits of indirection on GetRtpSources; that's all going to go directly to RTCRtpReceiver now. None of this code is being moved elsewhere.
Depends on D50395
Differential Revision: https://phabricator.services.mozilla.com/D64234
--HG--
extra : moz-landing-system : lando
This means we won't have to re-implement all of our JSImpl workarounds in c++.
Also, rename a variable in a way that made it easier to read this code.
Differential Revision: https://phabricator.services.mozilla.com/D50395
--HG--
extra : moz-landing-system : lando
This essentially implements the "queue a task" step required by the spec, which
ensures that if JS checks stats multiple times without relinquishing the event
loop, it will see the same thing each time.
Differential Revision: https://phabricator.services.mozilla.com/D64468
--HG--
extra : moz-landing-system : lando
Primarily, this removes code that was compensating for inconsistencies between webrtc.org's timestamps, and JS timestamps. Also, this removes a few bits of indirection on GetRtpSources; that's all going to go directly to RTCRtpReceiver now. None of this code is being moved elsewhere.
Depends on D50395
Differential Revision: https://phabricator.services.mozilla.com/D64234
--HG--
extra : moz-landing-system : lando
This means we won't have to re-implement all of our JSImpl workarounds in c++.
Also, rename a variable in a way that made it easier to read this code.
Differential Revision: https://phabricator.services.mozilla.com/D50395
--HG--
extra : moz-landing-system : lando
We're seeing what looks like occasional late callbacks in
VideoCaptureImpl::DeliverCapturedFrame on OS X. When we call stopCapture, it in
turns calls directOutputToNil which should cause any newly capture frames to be
dropped. It is not clear from the existing code or the documentation what would
happen to any frames which are already enqueued. It looks like it is possible
for frames to be delivered on the old queue, which would explain late callbacks.
Differential Revision: https://phabricator.services.mozilla.com/D67486
--HG--
extra : moz-landing-system : lando
This allows us to continue adding remaining interfaces from addrs array and
makes sure nr_interface_prioritizer_sort_preference() is called at the end.
Differential Revision: https://phabricator.services.mozilla.com/D66941
--HG--
extra : moz-landing-system : lando
In order to be able to change the audio output device, the device id is exposed to the constructor of MediaStreamGraph. Any component that gets/creates an MTG will be able to provide the device id in order to determine the desired output device. If the provided device id is null the default device will be used.
Differential Revision: https://phabricator.services.mozilla.com/D64133
--HG--
extra : moz-landing-system : lando
It looks like the overload of OnMouseCursorPosition which actually sets the
cursor_state_ member was somehow missed during the last webrtc.org update.
This overload is present in branch 64 upstream, but has subsequently been
removed.
Differential Revision: https://phabricator.services.mozilla.com/D66796
--HG--
extra : moz-landing-system : lando
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
