We need to join the multicast group on all network interfaces or we may end up
missing packets. There is a limit on the number of groups joinable by a single
socket (20 on my Linux system) but it doesn't seem worth worrying about
hitting that limit at the moment as it seems unlikely that many users would
have more than 20 network interfaces on a system on which they are running
Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D46981
--HG--
extra : moz-landing-system : lando
This adds Rust unit tests for some of the edge cases in handling queries
like limits and retries.
Differential Revision: https://phabricator.services.mozilla.com/D46980
--HG--
extra : moz-landing-system : lando
This limits the number of pending mDNS queries to 50, adds support for
retrying queries if they timeout, and support for reporting failure if a query
times out twice in a row.
Differential Revision: https://phabricator.services.mozilla.com/D46979
--HG--
extra : moz-landing-system : lando
We don't want web content to use mDNS to map out the local network, so
we only support registering and querying hostnames that are valid
UUIDs (followed by .local).
Differential Revision: https://phabricator.services.mozilla.com/D46978
--HG--
extra : moz-landing-system : lando
This adds basic query support to the mdns_service. Support for limiting
the number of pending queries, timeouts and retries is added in
another commit in this series.
Differential Revision: https://phabricator.services.mozilla.com/D46975
--HG--
extra : moz-landing-system : lando
I've reworked the includes in most of the files I've touched since I was adding
GMPLog.h:
- Reordered the includes to better match the Google C++ style.
- Removed includes that are already included from the associated header or
GMPLog.h. I.e. if Foo.cpp includes Foo.h, and Foo.cpp includes other headers
already included in Foo.h, these were removed.
Depends on D47194
Differential Revision: https://phabricator.services.mozilla.com/D47373
--HG--
extra : moz-landing-system : lando
This patch changes instances where the GMP MOZ_LOG is used to prefer using
macros from GMPLog.h:
- Files that don't need their own macros now just directly call
`GMP_LOG_<LEVEL>` as required.
- Files that use their own macros for formatting have had those macro
definitions changes so that the macros have unique names and are expressed in
terms of the macros from GMPLog.h.
I've also made a couple of drive by edits to logs so that they log more than a
couple of words and updated some strings where the incorrect class name was
being logged.
Differential Revision: https://phabricator.services.mozilla.com/D47194
--HG--
extra : moz-landing-system : lando
- Update README_MOZILLA for adding mp3 support, and add some clarifying text.
- Clang-format config.h for easier reading since it is our file, not ffmpeg's.
- Use sort -d -u to produce defaults_disabled.* files so linux and macOS
produce same files.
- Change MOZ_FFVPX_FLACONLY to MOZ_FFVPX_AUDIOONLY since it indicates flac
and mp3 decoders.
- Rename config_flac.h to config_audio.h
Differential Revision: https://phabricator.services.mozilla.com/D46423
--HG--
rename : media/ffvpx/config_flac.h => media/ffvpx/config_audio.h
extra : moz-landing-system : lando
Also, since OnProxyAvailable always happens on main regardless of the target we
set, don't bother setting the target.
Differential Revision: https://phabricator.services.mozilla.com/D46603
--HG--
extra : moz-landing-system : lando
Video capture used to provide device change notifications for audio and video devices. From now on, CubebDeviceEnumerator will provide audio device change notifications thus video capture is updated to notify only changes of the video device. This is the windows part.
Differential Revision: https://phabricator.services.mozilla.com/D46274
--HG--
extra : moz-landing-system : lando
Video capture used to provide device change notifications for audio and video devices. From now on, CubebDeviceEnumerator will provide audio device change notifications thus video capture is updated to notify only changes of the video device. This is the OSX part.
Differential Revision: https://phabricator.services.mozilla.com/D46273
--HG--
extra : moz-landing-system : lando
Video capture used to provide device change notifications for audio and video devices. From now on, CubebDeviceEnumerator will provide audio device change notifications thus video capture is updated to notify only changes of the video device. This is the Linux part.
Differential Revision: https://phabricator.services.mozilla.com/D46272
--HG--
extra : moz-landing-system : lando
After Bug 1581193 devicechange notifications were triggered with any device change, not just video and audio devices. This patch limits down the notifications to only video and audio input devices change.
Differential Revision: https://phabricator.services.mozilla.com/D46147
--HG--
extra : moz-landing-system : lando
The Telemetry::AccumulateTimeDelta function reports in milliseconds but I had
assumed seconds when I added the hostname obfuscation ICE duration histogram.
This change adjusts the "high" value accordingly.
With the telemetry we've collected to date, 60% of the values are below 600
milliseconds, so I think that setting a high value of 30 seconds should be
sufficient even if there is a long tail. Since this does not change the data
being collected, no additional data-review is required, but it does require
renaming the key.
Differential Revision: https://phabricator.services.mozilla.com/D46045
--HG--
extra : moz-landing-system : lando
This restores the code for generating devicechange events that was
accidentally removed as part of updating the Windows video capture code
in Bug 1552755.
Differential Revision: https://phabricator.services.mozilla.com/D46033
--HG--
extra : moz-landing-system : lando
Bug 1568101/D40532 captures the input timestamp and uses it in the resolve
function. However, there could be multiple encoded frames returned (e.g.,
for Drain()), and all of them will get the same captured timestamp. Read
back the timestamp from encoded data makes sure every frame gets the right
value. Also convert it for EncodedImage::_timeStamp uses different unit.
Differential Revision: https://phabricator.services.mozilla.com/D45774
--HG--
extra : moz-landing-system : lando
Freeing the conduits when the transceiver is stopped releases all of the
associated webrtc.org objects which results in substantial memory savings.
On my system, with an opt+debug build and 200 stopped transceivers, I see
373.17 MB of memory use in the content process without this patch, and
158.93 MB of memory use with this patch applied.
Going further and calling Shutdown_m as part of Stop() reduces the memory
use to 157.98 MB, which seems like a marginal improvement at the cost of
a much larger risk of introducing bugs.
Differential Revision: https://phabricator.services.mozilla.com/D45845
--HG--
extra : moz-landing-system : lando
With NSS now being used to do the decryption in the Clearkey CDM, remove the
source and licensing information related to OpenAES.
Differential Revision: https://phabricator.services.mozilla.com/D45205
--HG--
extra : moz-landing-system : lando
I just copied all the files from the upstream repository into the
rsdparsa directory
Differential Revision: https://phabricator.services.mozilla.com/D45717
--HG--
extra : moz-landing-system : lando
Having a full VPATH for the srcdir sometimes causes make to grab the
wrong prerequisite for a rule, in particular if we have a file in the
srcdir and also generate a file of the same name in the objdir. We don't
really need VPATH anymore though, since most of the information comes
from mozbuild, where we can explicitly list the path to the srcdir or
objdir as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D42968
--HG--
extra : moz-landing-system : lando
Clearkey previously relied on OpenAES to do its encryption. In order to
facilitate future changes and the need for CBC support, switch to NSS, which
should be more flexible and actively maintained.
Differential Revision: https://phabricator.services.mozilla.com/D41993
--HG--
extra : moz-landing-system : lando
This adds a mObfuscateHostAddresses member and uses it to control whether or
not peer reflex candidates are redacted. It is only necessary to keep track of
signaled addresses to support redacting peer reflex candidates, so there is no
need to store them if host address obfuscation is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D44531
--HG--
extra : moz-landing-system : lando
To accomodate this, MediaStreamTrackListener::NotifyEnded/Removed get an
additional aGraph argument. NotifyEnabledStateChanged is getting it too, for
completion.
Differential Revision: https://phabricator.services.mozilla.com/D43667
--HG--
extra : moz-landing-system : lando
The Rust get_if_addrs library previously used does not build on Android with
our build system. Since we're already using nICEr to determine the local
interface addresses, rather than fix the Rust library, we can use those
addresses to set the interface on which mdns_service listens.
Differential Revision: https://phabricator.services.mozilla.com/D42760
--HG--
extra : moz-landing-system : lando
Checking this assertion outside of the if statement can result in
a use-after-free in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D42152
--HG--
extra : moz-landing-system : lando
The current code causes one mDNS service to be created for each PeerConnection.
Due to Bug 1569311, the services persist until shutdown, which can lead to a
lot of mDNS threads running on sites which use WebRTC for fingerprinting. This
change makes it so we start at most one mDNS service.
I've filed Bug 1569955 to look at shutting down the mDNS service after the
last hostname is unregistered. As an alternative, if we fix Bug 1569311, we
could also use refcounting and stop the mDNS service after the last
StunAddrsRequestParent is freed.
Differential Revision: https://phabricator.services.mozilla.com/D42151
--HG--
extra : moz-landing-system : lando
With the move to the socket process, the UUID service is no longer available
in nricectx. This adds a pair of helper functions to mdns_service to generate
UUIDs and uses them to generate hostnames inside nricectx.
Differential Revision: https://phabricator.services.mozilla.com/D42150
--HG--
extra : moz-landing-system : lando
This only enables mDNS on OS X for now. Some versions of Windows lack mDNS
support, there are some oddities with resolving IPv6 addresses on Linux, and
Android has not yet been tested. All of these will be addressed in follow on
bugs.
Differential Revision: https://phabricator.services.mozilla.com/D38496
--HG--
extra : moz-landing-system : lando
This adds a mdns_service to mtransport to handle responding to mDNS queries.
All hostnames will be generated from UUIDs, so the responder assumes that it
is the only responder for a hostname which is registered with it. Because of
this, the responder does not first make a DNS query itself to see if any other
responder is handling a hostname, and does not wait a random amount of time
before replying, both of which are required by the specification to avoid
collisions with other responders.
Differential Revision: https://phabricator.services.mozilla.com/D38489
--HG--
extra : moz-landing-system : lando
The Rust get_if_addrs library previously used does not build on Android with
our build system. Since we're already using nICEr to determine the local
interface addresses, rather than fix the Rust library, we can use those
addresses to set the interface on which mdns_service listens.
Differential Revision: https://phabricator.services.mozilla.com/D42760
--HG--
extra : moz-landing-system : lando
Checking this assertion outside of the if statement can result in
a use-after-free in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D42152
--HG--
extra : moz-landing-system : lando
The current code causes one mDNS service to be created for each PeerConnection.
Due to Bug 1569311, the services persist until shutdown, which can lead to a
lot of mDNS threads running on sites which use WebRTC for fingerprinting. This
change makes it so we start at most one mDNS service.
I've filed Bug 1569955 to look at shutting down the mDNS service after the
last hostname is unregistered. As an alternative, if we fix Bug 1569311, we
could also use refcounting and stop the mDNS service after the last
StunAddrsRequestParent is freed.
Differential Revision: https://phabricator.services.mozilla.com/D42151
--HG--
extra : moz-landing-system : lando
With the move to the socket process, the UUID service is no longer available
in nricectx. This adds a pair of helper functions to mdns_service to generate
UUIDs and uses them to generate hostnames inside nricectx.
Differential Revision: https://phabricator.services.mozilla.com/D42150
--HG--
extra : moz-landing-system : lando
This only enables mDNS on OS X for now. Some versions of Windows lack mDNS
support, there are some oddities with resolving IPv6 addresses on Linux, and
Android has not yet been tested. All of these will be addressed in follow on
bugs.
Differential Revision: https://phabricator.services.mozilla.com/D38496
--HG--
extra : moz-landing-system : lando
This adds a mdns_service to mtransport to handle responding to mDNS queries.
All hostnames will be generated from UUIDs, so the responder assumes that it
is the only responder for a hostname which is registered with it. Because of
this, the responder does not first make a DNS query itself to see if any other
responder is handling a hostname, and does not wait a random amount of time
before replying, both of which are required by the specification to avoid
collisions with other responders.
Differential Revision: https://phabricator.services.mozilla.com/D38489
--HG--
extra : moz-landing-system : lando
This changes the hard-limit of `RLIMIT_RTTIME` to be the maximum available
(200ms on my system), and keep the soft limit to the same number.
Having different numbers allow catching SIGXCPU before getting SIGKILL.
Differential Revision: https://phabricator.services.mozilla.com/D43402
--HG--
extra : moz-landing-system : lando
In InitDecode it is possible for mDecoder to be null if the CreateDecoder call
fails, in which case an error code is returned. Release is called by
GenericDecoder::~VCMGenericDecoder regardless of whether InitDecode succeeds, so
we need to check if mDecoder is null in Release.
Differential Revision: https://phabricator.services.mozilla.com/D43469
--HG--
extra : moz-landing-system : lando
This changes the hard-limit of `RLIMIT_RTTIME` to be the maximum available
(200ms on my system), and keep the soft limit to the same number.
Having different numbers allow catching SIGXCPU before getting SIGKILL.
Differential Revision: https://phabricator.services.mozilla.com/D43402
--HG--
extra : moz-landing-system : lando
In OnIncomingFrame() we check if the capture has started by calling
CaptureStarted() which holds a lock. If StopCapture() is called on the
control thread after we check CaptureStarted() it is possible that
_captureCapability will be zeroed out prior to frame being delivered because
the lock has been released. This would result in an unknown video type in
CalcBufferSize() and trigger an assertion there. This creates a local copy of
_captureCapability with the lock held to ensure it is not zeroed out when the
frame is delivered.
Differential Revision: https://phabricator.services.mozilla.com/D42338
--HG--
extra : moz-landing-system : lando
This adds a field to about:webrtc which indicates whether an associated
candidate is behind a proxy or not.
Differential Revision: https://phabricator.services.mozilla.com/D39974
--HG--
extra : moz-landing-system : lando
If the remote IP address and port number are unable to be converted to a
transport address, the context was incorrectly left with a pointer to zeroed
out memory, which causes nr_ice_get_default_local_address() to abort. Freeing
the address and setting the pointer to null on failure should allow the
fallback to be used to retrieve the default local address.
Differential Revision: https://phabricator.services.mozilla.com/D42661
--HG--
extra : moz-landing-system : lando
As this class is not only used for creating decoder, also for encoder, it's more proper to rename it as `MediaDataCodec`.
Differential Revision: https://phabricator.services.mozilla.com/D41443
--HG--
rename : media/webrtc/signaling/src/media-conduit/MediaDataDecoderCodec.cpp => media/webrtc/signaling/src/media-conduit/MediaDataCodec.cpp
rename : media/webrtc/signaling/src/media-conduit/MediaDataDecoderCodec.h => media/webrtc/signaling/src/media-conduit/MediaDataCodec.h
extra : moz-landing-system : lando
Use `BitrateAdjuster` to calculate bitrate and prevent to set bitrate too often, because certain hardware encoders tend to consistently overshoot the bitrate that they are configured to encode at.
Differential Revision: https://phabricator.services.mozilla.com/D40533
--HG--
extra : moz-landing-system : lando
In order to encode video frame, we have to convert `webrtc::VideoFrame` to gecko's video data, and then send this YUV-based video data to the encoder.
The encoder won't return an encoded frame everytime when we call its `encode()`, so we have to wait until there are valid samples added to `mEncodedFrames`.
Then, convert the `MediaRawData` to `webrtc::EncodedImage` and provide an NAL entries list to indicate where the NALs are in the encoded bytes stream and how large they are. We would send those data back
to the consumer of the encoder via calling a callback function `OnEncodedImage()`.
Differential Revision: https://phabricator.services.mozilla.com/D40532
--HG--
extra : moz-landing-system : lando
`RefCountedWebrtcVideoEncoder` is a generic interface which supports refcounting, using that can ensure the encoder is always alive even if using it in an async task.
So now both `WebrtcGmpVideoEncoder` and `WebrtcMediaDataEncoder` would inherit from `RefCountedWebrtcVideoEncoder`.
We can use `WebrtcVideoEncoderProxy` to wrap them and return `WebrtcVideoEncoderProxy` for the use in the WebRTC pineline.
Differential Revision: https://phabricator.services.mozilla.com/D41855
--HG--
extra : moz-landing-system : lando
In this patch, we implement how to create a platform encoder, init an encoder and release it when we don't need it anymore.
In addition, as the encoder factory only supports h264 for now, so all configuration related to encoder would be h264 specific.
Differential Revision: https://phabricator.services.mozilla.com/D40531
--HG--
extra : moz-landing-system : lando
Implement a basic interface for `WebrtcMediaDataEncoder`, which will only be used on OSX for encoding h264 only.
Differential Revision: https://phabricator.services.mozilla.com/D40529
--HG--
extra : moz-landing-system : lando
The stack from crash report suggests that ChildImpl was deleted at the end of function GetOrCreateSocketActorForCurrentThread(). This only happens when SendInitBackground failed, so we have to close the IPC channel before ChildImpl getting destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D40838
--HG--
extra : moz-landing-system : lando
Previously, the network.webRTCIPHandlingPolicy "disable_non_proxied_udp" only
enabled the use of WebRTC if a proxy was configured and the WebRTC service
supported TURN TCP.
This aims to match Chrome's behavior by forcing the use of a proxy if one is
configured, otherwise falling back to mode 3 (no host candidates and default
route only).
Also, remove some dead code left over from the old way of routing TURN
communications through an HTTP proxy.
Differential Revision: https://phabricator.services.mozilla.com/D37892
--HG--
extra : moz-landing-system : lando
- Don't import the build settings since the settings in gecko is more
complicated.
- Print out the picked commits when running the scripts
Differential Revision: https://phabricator.services.mozilla.com/D40097
--HG--
extra : moz-landing-system : lando
This is inherently large, because modifying these bits of DOMMediaStream and
MediaStreamTrack affects all consumers and producers of all DOMMediaStreams and
MediaStreamTracks.
Things are generally much simpler now.
Producers of tracks now create a MediaStream in the graph, add it to a
MediaStreamTrackSource subclass that takes ownership of it, and add the source
to a MediaStreamTrack. Should the producer need a DOMMediaStream it is now much
simpler to create as the only thing needed is the current window. The stream is
a rather simple wrapper around an array of MediaStreamTracks.
HTMLMediaElement is still not as straight forward as other consumers since it
consumes the DOMMediaStream directly, as opposed to a set of tracks.
The new MediaStreamRenderer helper class helps bridge the gap between this fact
and the new track-based MediaStreamGraph interface, as it needs to juggle
registering multiple audio tracks for audio output. This hooks into existing
HTMLMediaElement logic and brings a welcome simplification to all the glue
previously needed there.
Differential Revision: https://phabricator.services.mozilla.com/D37934
--HG--
extra : moz-landing-system : lando
This ensures all clones of the original track also receives the new muted state.
Differential Revision: https://phabricator.services.mozilla.com/D37933
--HG--
extra : moz-landing-system : lando
They're infallible in practice and always `NS_OK`. (This stems from
`AddVarCacheNoAssignment()` always returning `NS_OK`.)
As a result, the commit removes lots of unnecessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D39804
--HG--
extra : moz-landing-system : lando
When unknown, we rely on the picture height and assume that anything less than 720p is 601 and 709 otherwise. It's not perfect but it's the best we can do.
Differential Revision: https://phabricator.services.mozilla.com/D39275
--HG--
extra : moz-landing-system : lando
When unknown, we rely on the picture height and assume that anything less than 720p is 601 and 709 otherwise. It's not perfect but it's the best we can do.
Differential Revision: https://phabricator.services.mozilla.com/D39275
--HG--
extra : moz-landing-system : lando
When unknown, we rely on the picture height and assume that anything less than 720p is 601 and 709 otherwise. It's not perfect but it's the best we can do.
Differential Revision: https://phabricator.services.mozilla.com/D39275
--HG--
extra : moz-landing-system : lando
This is the most immediate solution to the problem. This is how
automation ends up building things because it's cross-compiling and
cross-compiling falls back to the code path of that feature, and this
solves the immediate problem of builds not working out of the box.
The more long term fix would be to fix the coreaudio-sys crate to do the
right thing.
Differential Revision: https://phabricator.services.mozilla.com/D39447
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Fall back to using Google's DNS server to determine the associated local
addresses for web applications that are not loaded over the network. This
includes the loopback address, which is frequently used in the unit tests.
Provide a separate function for setting the target for the default local
address lookup.
Differential Revision: https://phabricator.services.mozilla.com/D37331
--HG--
extra : moz-landing-system : lando
draft-ietf-rtcweb-ip-handling specifies that the default route is the route
used to reach the origin rather than the one used to reach the internet, so
update the IP routing to reflect this. This addresses issues in which the
wrong IP address is used on machines with multiple network interfaces.
Differential Revision: https://phabricator.services.mozilla.com/D36831
--HG--
extra : moz-landing-system : lando
