Port restriction is delegated to the io service. Port 0 is explicitly
unrestricted.
NS_CheckPortSafety emits a warning which pollutes the gtests a bit. It is only
tested if the port is not 0.
Differential Revision: https://phabricator.services.mozilla.com/D13187
--HG--
extra : moz-landing-system : lando
Assertions in NetEqImpl::SetSampleRateAndChannels prevent us from requesting
tones at 44100 Hz, so this code can be safely removed.
Differential Revision: https://phabricator.services.mozilla.com/D12982
--HG--
extra : moz-landing-system : lando
This enables support for the DirectX screen capturer. We use the default
DesktopCaptureOptions which do not set the option to use the DirectX screen
capturer so this change will have no effect with the current code.
For what it's worth, I tested enabling the DirectX option and it worked fine on my
system, but I don't see any reason to not follow the defaults provided by
webrtc.org in this case.
Differential Revision: https://phabricator.services.mozilla.com/D13303
--HG--
extra : moz-landing-system : lando
Historically this code was part of webrtc.org but has since been removed
from upstream. Rather than maintaining it as a local diff against upstream,
we should just move it to where it is used.
Differential Revision: https://phabricator.services.mozilla.com/D13092
--HG--
rename : media/webrtc/trunk/webrtc/video_engine/browser_capture_impl.h => dom/media/systemservices/video_engine/browser_capture_impl.h
rename : media/webrtc/trunk/webrtc/video_engine/desktop_capture_impl.cc => dom/media/systemservices/video_engine/desktop_capture_impl.cc
rename : media/webrtc/trunk/webrtc/video_engine/desktop_capture_impl.h => dom/media/systemservices/video_engine/desktop_capture_impl.h
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
--HG--
extra : moz-landing-system : lando
Make a cleaner distinction between having a recv stream that is inactive, and no recv stream at all. Requires some modification to local RTC extension configuration, because of a test-case that assumed StopReceiving/StartReceiving would re-create the recv stream as opposed to simply restarting it.
Differential Revision: https://phabricator.services.mozilla.com/D12936
--HG--
extra : moz-landing-system : lando
Replace README_MOZILLA with moz.yaml, various fixups for update.py, and create
a missing patch file from Bug 1491848.
Differential Revision: https://phabricator.services.mozilla.com/D11891
--HG--
extra : moz-landing-system : lando
This removes DecodedStream's use of MediaStreamListener in favor of
MediaStreamTrackListener. This change has however rippled through to a lot
more cleanup, per below.
This moves the MediaStreamTrack lifetime ownership for captured
HTMLMediaElements from the media element to DecodedStream, where the
MediaStreamGraph-side tracks are already created and ended today.
This makes MediaStreamTrack creation explicit across the entire codebase and
lets us remove the MediaStreamTrackSourceGetter class and the infrastructure
of adding MediaStreamTracks after they've already been created in the graph
from DOMMediaStream.
With track ownership, and thus TrackID allocation ownership, happening
exclusively in DecodedStream for its output tracks, we also stop throwing
away and recreating the SourceMediaStream to which we feed data on seek.
This is one step closer to fixing bug 1172394 and spec compliance of
HTMLMediaElement.captureStream().
Differential Revision: https://phabricator.services.mozilla.com/D12273
--HG--
extra : moz-landing-system : lando
This allows DecodedStream to accurately track how many samples have been
appended to a track, even with resampling enabled.
Differential Revision: https://phabricator.services.mozilla.com/D12272
--HG--
extra : moz-landing-system : lando
Bug 1489040 - P1 - Update WebRTC ICE candidate stats field ipAddress to new name, address
Bug 1489040 - P2 - adjust WebRTC stats mochitest for new stat name 'address'
Bug 1489040 - P3 - add test for legacy WebRTC stat names
Differential Revision: https://phabricator.services.mozilla.com/D5560
--HG--
extra : moz-landing-system : lando
This makes Init and DeleteChannels virtual and mRecvChannelProxy and
mSendChannelProxy protected. This will allow unit test code to override
the creation of channels so that we can use a mocked ChannelProxy instead.
Depends on D12016
Differential Revision: https://phabricator.services.mozilla.com/D12017
--HG--
extra : moz-landing-system : lando
Rather than returning an error, the channel proxies have asserts that the
underlying calls to the channel objects succeeded.
Depends on D12015
Differential Revision: https://phabricator.services.mozilla.com/D12016
--HG--
extra : moz-landing-system : lando
This was regressed by the branch 64 update. The parameter is used in
audio_encoder_opus.cc.
Depends on D12014
Differential Revision: https://phabricator.services.mozilla.com/D12015
--HG--
extra : moz-landing-system : lando
Packet size and rate are no longer configured inside AudioConduit, so there is
no reason to continue to define them here. We now take the defaults provided
by webrtc.org.
Depends on D12012
Differential Revision: https://phabricator.services.mozilla.com/D12013
--HG--
extra : moz-landing-system : lando
With the branch 64 update we no longer configure packet size and rate
ourselves. Instead, we use the defaults provided in acm_codec_database.cc.
This removes the unused fields from AudioCodecConfig, the next commit does the
same thing for JsepAudioCodecDescription.
Differential Revision: https://phabricator.services.mozilla.com/D12012
--HG--
extra : moz-landing-system : lando
Includes changes to support nasm's stricter include paths.
Supports falling back to yasm if nasm is missing.
Differential Revision: https://phabricator.services.mozilla.com/D9972
--HG--
extra : moz-landing-system : lando
Add moz.yaml and update `update.sh` to match other media libraries.
Note after upstream's switch from SVN to git the RSC headers have changed,
however, these changes have not yet been committed. I've updated the patch
that had hunks with context extending into the RSC header so it continues to
apply after pulling from git.
Differential Revision: https://phabricator.services.mozilla.com/D11975
--HG--
extra : moz-landing-system : lando
This replaces the tunnel using a new nr_socket implementation. Proxy detection
code is still done in the peer connction. However, the result is only used to
detect a proxy. The result is unused. Address resolution is done by necko code
in the parent process. The new socket wraps a WebrtcProxyChannel which uses
necko to handle proxy negotiation. This has a happy side effect of enabling all
authentication modes that necko already supports for http proxies.
This adds a protocol for Necko to manage, WebrtcProxyChannel. This new protocol
serves as a pipe for a CONNECT tunnel. It is only used in WebRtc and not built
in no WebRtc builds.
--HG--
extra : rebase_source : a951841f95eaaa0562886cf76b405b01f1adf70e
extra : intermediate-source : 5c3da21957fc80b07188bc8a405437b858027a22
extra : source : 594a32883463ab051677ba06e22fa6d062b4b4a9
Summary:
The current default stack size of 1M results in intermittent OOMs on win32
builds while running web-platform tests. The value of 256k was chosen for
consistency with the default value used elsewhere in Gecko, which is defined in
nsIThreadManager.idl.
Reviewers: bwc
Tags: #secure-revision
Bug #: 1376873
Differential Revision: https://phabricator.services.mozilla.com/D11090
--HG--
extra : rebase_source : 9039a5c4ac25c227ee65b0321fdffdecd81d085c
All gn-configs were generated on a single FreeBSD amd64 machine:
- DragonFly and NetBSD have is_clang=false, so differ only in target_os/OS_TARGET
- FreeBSD and OpenBSD have is_clang=true, so differ only in target_os/OS_TARGET
- x86 (i386) configs are from 32-bit chroot on x86_64 (amd64)
- arm (armv7) and arm64 (aarch64) configs are from qemu-user chroot
- qemu-user can't run rustc atm, so configure was hacked to work without
- qemu-user crashes with gn 68 on aarch64, so gn 65 was used
--HG--
extra : rebase_source : fb05d660c299851de6226fb23c6873bdfc34237f
This updates the gn generated json files for tier-1 platforms, and removes
the outdated configurations for remaining platforms.
--HG--
extra : rebase_source : bccb7a5476d5d0a66aa90657f839cea5e49ff4ce
The VP8SimulcastAdapter automatically handles cropping to accomodate
constraints on VP8 simulcast streams that each stream have exactly half the
width and height of the higher resolution stream before it.
This also adjusts min_bitrate_estimate in
test_peerConnection_simulcastOddResolution.html to compensate for changes in
the simulcast resolutions chosen by the webrtc.org code.
Differential Revision: https://phabricator.services.mozilla.com/D7482
--HG--
extra : rebase_source : b7ea403f7c9d6175a34eb11c7af17dd12ee55c31
This fixes a bug in the upstream code introduced when they removed the
ConvertToI420 helper method from webrtc_libyuv.cc. The buffer size is
passed into libyuv::ConvertI420 incorrectly when rotation is applied, which
causes bad rendering and instabilities.
Differential Revision: https://phabricator.services.mozilla.com/D7478
--HG--
extra : rebase_source : d6910e01ebd81a626b6924f04b31f37b87900a66
Windows ASAN builds complain about attempting to cast away the const qualifier
in FunctionThatDoesNothing, so this makes the argument const.
Differential Revision: https://phabricator.services.mozilla.com/D7477
--HG--
extra : rebase_source : dbfa0a48f50c30afa5a41b81af32bd9744a31511
Upstream has added an assertion in video send stream that prevents using
ReconfigureVideoEncoder if the content type has changed. This adds a
mActiveCodecMode member and uses it to prevent calling that method if the
codec mode has changed.
Differential Revision: https://phabricator.services.mozilla.com/D7475
--HG--
extra : rebase_source : d6af217ae501163f6ee742f2ad48f1f22d2869b4
This is no longer necessary as we do not use the webrtc.org audio device
implementations anymore.
Differential Revision: https://phabricator.services.mozilla.com/D7450
--HG--
extra : rebase_source : b0fb79e68885b42afa1418c77bc6d24527803e9c
This uses sync groups in the receive stream configs for the conduits rather
than establishing sync through direct calls. When the streams are created
in call.cc, ConfigureSync is called, which results in SetSync being called
on the video stream which is the replacement for SetSyncChannel in branch 57
of webrtc.org.
With the current code, a video stream can only be synchronized to a single
audio stream. Using sync groups enforces a stronger constraint that only one
pair of audio and video streams can be synchronized for each sync group. The
comments in call.cc imply this is what is supported by webrtc.org, it seems
safer to also follow this constraint rather than circumvent it by calling
directly into the underlying code.
Differential Revision: https://phabricator.services.mozilla.com/D7445
--HG--
extra : rebase_source : fa8b1d301398edcedc6e488c51009b6667792f45
We went through a lot of trouble to plumb the CPULoadState down to
MediaOptimization, but the value is not actually used for anything, at least
since the Branch 57 update. This removes the plumbing, since it seems we are
getting along ok without it.
Differential Revision: https://phabricator.services.mozilla.com/D7443
--HG--
extra : rebase_source : e8f7c8b313d37ea3383a9eb16a6cc573844762cd
The only use of Mid in the current webrtc.org code is in the unit tests.
RtpStreamReceiverController only allows adding sinks using SSRCs. Because
of this, we'll end up dropping packets in the RtpDemuxer with the current
code as none of our Mids will be recognized.
Tip of webrtc.org fully supports using Mids, so we'll be able to enable this
code again after the next update.
Differential Revision: https://phabricator.services.mozilla.com/D7442
--HG--
extra : rebase_source : 89d0f100bfa8bf7c050f6176f21dc2c829503d82
The changes to Call are required because we create the Call object on the main
thread, but deliver packets and query stats from the socket thread.
The changes to ChannelProxy are required because we query stats from the
socket thread rather than the main thread.
For RtpVideoStreamReceiver, this removes the worker_task_checker_ assertions
and replaces them with a critical section. This is how the code worked prior
to this update. We create the Call object (and thus eventually the
RtpVideoStreamReceiver) on the main thread, but we want to deliver packets on
the socket thread. To retain these assertions we'd either have to dispatch calls
to deliver packets from the socket thread to the main, which seems pretty bad
from a performance point of view, or we'd have to refactor the code to create
the Call object on the socket thread, which seems like a major refactoring
best done outside of a branch update. Going back to the previous behaviour
seemed like the least bad alternative.
Differential Revision: https://phabricator.services.mozilla.com/D7440
--HG--
extra : rebase_source : f427225442dba10683f3928add8059a3630aafe5
We'll need to queue rtp packets in both the AudioConduit and the VideoConduit.
This adds a class to manage the packet queue to reduce duplicated code between
the conduits.
Differential Revision: https://phabricator.services.mozilla.com/D7439
--HG--
extra : rebase_source : c1463a44fbfe235f2f3a540c64d93a52a2b2e2ca
Support for native_handle() has been removed by upstream.
Differential Revision: https://phabricator.services.mozilla.com/D7437
--HG--
extra : rebase_source : e37659e718c58d0de7504ddffa15043ff18a603c
This updates the copy of sigslot used by mtransport to match that used by
webrtc.
Differential Revision: https://phabricator.services.mozilla.com/D7436
--HG--
extra : rebase_source : f10b94988654b09ec2f88269c26f61ad3c50e0bd
This makes the ImageBuffer class implement VideoFrameBuffer class and makes
it available in MediaPipeline. To avoid exposing MediaPipeline to a lot of
internal details of WebrtcMediaDataDecoder, ImageBuffer is moved to its
own header file.
We're required to implement a ToI420() method. I've re-used the current
implementation of NativeToI420Buffer, which requires more development in order
to work properly as the Image class only supports RGB readback.
Differential Revision: https://phabricator.services.mozilla.com/D7435
--HG--
extra : rebase_source : 19ec409510f06a9fa7cab15c1f16c9a7bad0b433
