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
