This patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
Similar to changes for Bug 1303867 to make sure we destroy the NrIceMediaStream
after removing the transport.
Depends on D85204
Differential Revision: https://phabricator.services.mozilla.com/D88924
Partial implementation of RTCDtlsTransport (state and onstatechange)
for wfh. Stubbed out methods so everything builds.
Differential Revision: https://phabricator.services.mozilla.com/D84459
Revert bug 1412240. It was a workaround for a LLVM bug and only
relevant when icecc is involved. Since sccache-dist is preferred
now, it's no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D87891
Previously it listened for them on main thread, as notified by the
MediaStreamTrack it was transmitting directly. With this patch it
listens for them through the TrackListener in the graph, and will
get notified when any track prior to the MediaStreamTrack's main
track in the graph changes enabled state as well.
Depends on D86926.
Differential Revision: https://phabricator.services.mozilla.com/D86931
Previously it listened for them on main thread, as notified by the
MediaStreamTrack it was transmitting directly. With this patch it
listens for them through the TrackListener in the graph, and will
get notified when any track prior to the MediaStreamTrack's main
track in the graph changes enabled state as well.
Depends on D86926.
Differential Revision: https://phabricator.services.mozilla.com/D86931
Previously it listened for them on main thread, as notified by the
MediaStreamTrack it was transmitting directly. With this patch it
listens for them through the TrackListener in the graph, and will
get notified when any track prior to the MediaStreamTrack's main
track in the graph changes enabled state as well.
Depends on D86926.
Differential Revision: https://phabricator.services.mozilla.com/D86931
It will now be up to the caller to determine where the decoder is going to run. This allows to simplify the audio decoders so that they can run synchronously and be wrapped in a Wasm sandbox (which doesn't support multi-threading)
The structure guarantees that all MediaDataDecoder methods are called on the same thread it's been initialised.
To achieve this, wherever a MediaDataDecoder was created, we wrap it in a MediaDataDecoderProxy that ensures that all methods are running on the given thread.
We keep the behaviour of all methods in all MediaDataDecoder to assert that they are running on the expected thread for diagnostic purposes. It could go in the future.
Video decoders that could block excessingly the thread on which they are called are made to run on their own task queue.
The Apple decoder is mostly entirely asynchronous, with the exception of the drain method which could block.
We exclude the android and omx decoders are the framework they use is 100% asynchronous and already operate on another thread.
Differential Revision: https://phabricator.services.mozilla.com/D86929
This adds the current browserId to the internal stats report. The peer
connections are sorted by browserId, and a "Show tab" button is added that will
select the tab associated with the peer connection to make it easier to keep
track of which peerconnection is associated with a tab.
Differential Revision: https://phabricator.services.mozilla.com/D86699
This interface extends nsIDNSRecord and makes the DNS code more extensible
by allowing us to support more record types.
This change does require the consumer to be aware of the type they requested
and to QueryInterface to either nsIDNSAddrRecord for regular IP lookups,
or to nsIDNSByTypeRecord for other kinds of lookups.
Differential Revision: https://phabricator.services.mozilla.com/D86177
This patch adds the nsIDNSResolverInfo interface which is used to hold
information about the resolver to be used in a DNS resolution.
We use this to merge all of the *WithTRRServer resolve functions into one.
Passing a resolver info will use that object when appropriate. No resolver
info means that we default to using the system resolver, or the default TRR
resolver.
This patch also converts the RESOLVE_TYPE_* flags into a cenum and adds
the resolveType as a parameter to asyncResolve thus removing the need
to have asyncResolveByType methods.
Differential Revision: https://phabricator.services.mozilla.com/D86176
This interface extends nsIDNSRecord and makes the DNS code more extensible
by allowing us to support more record types.
This change does require the consumer to be aware of the type they requested
and to QueryInterface to either nsIDNSAddrRecord for regular IP lookups,
or to nsIDNSByTypeRecord for other kinds of lookups.
Differential Revision: https://phabricator.services.mozilla.com/D86177
This patch adds the nsIDNSResolverInfo interface which is used to hold
information about the resolver to be used in a DNS resolution.
We use this to merge all of the *WithTRRServer resolve functions into one.
Passing a resolver info will use that object when appropriate. No resolver
info means that we default to using the system resolver, or the default TRR
resolver.
This patch also converts the RESOLVE_TYPE_* flags into a cenum and adds
the resolveType as a parameter to asyncResolve thus removing the need
to have asyncResolveByType methods.
Differential Revision: https://phabricator.services.mozilla.com/D86176
RCFILE is only actually used when the moz.build that contains it defines
a binary, which is not the case for dav1d, which ends up in gkmedias.dll.
Which also means that moving the definition to gkmedias would also not
make sense, since all dav1d.rc does is add descriptors to the dll that it
contains dav1d and what version, but gkmedias.dll contains other things
too.
Differential Revision: https://phabricator.services.mozilla.com/D86152
RCFILE is only actually used when the moz.build that contains it defines
a binary, which is not the case for dav1d, which ends up in gkmedias.dll.
Which also means that moving the definition to gkmedias would also not
make sense, since all dav1d.rc does is add descriptors to the dll that it
contains dav1d and what version, but gkmedias.dll contains other things
too.
Differential Revision: https://phabricator.services.mozilla.com/D86152
Chrome's SDP parser has problems with an ssrc-group being present if the media
section is inactive and does not have an msid.
Differential Revision: https://phabricator.services.mozilla.com/D85320
Nathan Froyd
Byron Campen [:bwc]
Michael Froman
Valentin Gosu
Nico Grunbaum
Jon Bauman
Butkovits Atila
John Lin
Andreas Pehrson
Bogdan Tara
Jean-Yves Avenard
Mike Hommey
Dan Minor
Simon Giesecke
Mihai Alexandru Michis
Jan-Ivar Bruaroey
Kershaw Chang
Noemi Erli
Sylvestre Ledru
Andreea Pavel