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
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
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
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
Left shifting a negative value results in undefined behaviour. It is safer to
multiply in this case.
Differential Revision: https://phabricator.services.mozilla.com/D48751
--HG--
extra : moz-landing-system : lando
Added playout-delay RTP header extension for video to JsepSessionImpl::SetupDefaultRtpExtensions.
This ensures that this extension will be preserved when generating an answer to an offer (by a sending peer) containing it.
Also updated JsepSessionTest to include a test verifying that the expected default audio and video extensions are set.
Differential Revision: https://phabricator.services.mozilla.com/D47689
--HG--
extra : moz-landing-system : lando
There is a window inside of SendPacket where the critical section is released
which means that other code could set paused_. This would lead to us hitting
the assertion at the top of SendPacket. Checking paused_ in the while loop
will avoid this. Upstream has fixed this problem in a similar way, but the
code has changed there enough that it doesn't make sense to try to bring in
their fix directly.
Differential Revision: https://phabricator.services.mozilla.com/D48540
--HG--
extra : moz-landing-system : lando
This is a partial cherrypick of https://webrtc.googlesource.com/src/+/f89110d67902e787f6745ad2b52f7f09fc808512.
The cropping changes in that revision are problematic on our version of webrtc.org and
result in distorted video, which looks as though there is a stride problem. This takes
the change to try to use PW_RENDERFULLCONTENT and to fall back to the current code if
that fails. This fixes capturing Chrome windows and allows Firefox to properly capture
its own window.
Using PW_RENDERFULLCONTENT can adversely affect performance. Using the
CroppingWindowCapturer can avoid using the WindowCapturer in some circumstances and so
result in better performance. Bug 1586071 tracks switching to the
CroppingWindowCapturer.
Differential Revision: https://phabricator.services.mozilla.com/D48108
--HG--
extra : moz-landing-system : lando
