With rtx enabled, we can't just switch ssrcs when we receive a packet with an
unrecognized ssrc. This changes the ReceiveRTPPacket call to take the entire
rtp header, and then examines the payload type. If the payload type is
associated with rtx or ulpfec, the ssrc will not be changed. This is what is
done by the libwebrtc unsignaled ssrc change code, so this behaviour should
match what Chrome does.
Differential Revision: https://phabricator.services.mozilla.com/D72230
This changes the constructor to not take any parameters for consistency
with how the other parameters are handled. It also fixes serialization, the
current code will output an ascii character rather than the numeric value.
Differential Revision: https://phabricator.services.mozilla.com/D72222
We currently retry sending queries on all failures to write to the socket on
the assumption that write errors represent transient errors. With this change,
we treat EPERM has a permanent error and drop queries if we see it. This is
not a problem when sending answers, as we don't retry in case of errors there,
on the assumption that the other side will retry their query in the future.
We do have code to limit the number of times we attempt an mDNS query, but we
didn't hit it in this case, because it only counts sends that are successful.
Differential Revision: https://phabricator.services.mozilla.com/D73492
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
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
Dan Minor
Sergio Garcia Murillo
Jean-Yves Avenard
Alex Chronopoulos
Simon Giesecke
Dorel Luca
Byron Campen [:bwc]
Matthew Gregan
Paul Adenot
Razvan Maries
Nico Grunbaum
Arthur Iakab
Kershaw Chang
Sylvestre Ledru
Michael Froman
Narcis Beleuzu
shravanrn@gmail.com
Brindusan Cristian
Chun-Min Chang
Jan Beich
Nils Ohlmeier [:drno]
Omri Sarig
Noemi Erli
Tom Tung
Andreas Farre
Valentin Gosu
Anthony Ramine
Emilio Cobos Álvarez
Cosmin Sabou
J. Ryan Stinnett
André Bargull
Jason
Jon Bauman
Bogdan Tara
Marcin Wojtczak
Kartikaya Gupta
Ed Lee
Kevin Jacobs
Ehsan Akhgari
Mike Shal
Tooru Fujisawa
Andrew McCreight
Ciure Andrei
Andrew Osmond
David Major