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
This allows newly created window listeners, in MediaManager instances where the
cameras have already been muted, to get the right state.
Differential Revision: https://phabricator.services.mozilla.com/D87127
Add UA (user agent) muting, a spec-supported feature that somewhat mirrors
track enabling/disabling, except only the browser controls it. The effect
on track sinks is additive: must be unmuted and enabled for there to be
output.
Fire mute/unmute events on JS, and observably set track.muted independent
of track.enabled (reusing existing infrastructure already in use by
RTCPeerConnection tracks).
Low-level: add mDeviceMuted and SetMutedFor() modeled after mDeviceEnabled
and SetEnabledFor() as parallel device state for both camera and microphone for
symmetry and maintenance.
High-level: Only expose messages to mute/unmute camera at the moment, since
that is what is immediately required for Android in bug 1564451.
Differential Revision: https://phabricator.services.mozilla.com/D84222
This allows newly created window listeners, in MediaManager instances where the
cameras have already been muted, to get the right state.
Differential Revision: https://phabricator.services.mozilla.com/D87127
Add UA (user agent) muting, a spec-supported feature that somewhat mirrors
track enabling/disabling, except only the browser controls it. The effect
on track sinks is additive: must be unmuted and enabled for there to be
output.
Fire mute/unmute events on JS, and observably set track.muted independent
of track.enabled (reusing existing infrastructure already in use by
RTCPeerConnection tracks).
Low-level: add mDeviceMuted and SetMutedFor() modeled after mDeviceEnabled
and SetEnabledFor() as parallel device state for both camera and microphone for
symmetry and maintenance.
High-level: Only expose messages to mute/unmute camera at the moment, since
that is what is immediately required for Android in bug 1564451.
Differential Revision: https://phabricator.services.mozilla.com/D84222
This allows newly created window listeners, in MediaManager instances where the
cameras have already been muted, to get the right state.
Differential Revision: https://phabricator.services.mozilla.com/D87127
Add UA (user agent) muting, a spec-supported feature that somewhat mirrors
track enabling/disabling, except only the browser controls it. The effect
on track sinks is additive: must be unmuted and enabled for there to be
output.
Fire mute/unmute events on JS, and observably set track.muted independent
of track.enabled (reusing existing infrastructure already in use by
RTCPeerConnection tracks).
Low-level: add mDeviceMuted and SetMutedFor() modeled after mDeviceEnabled
and SetEnabledFor() as parallel device state for both camera and microphone for
symmetry and maintenance.
High-level: Only expose messages to mute/unmute camera at the moment, since
that is what is immediately required for Android in bug 1564451.
Differential Revision: https://phabricator.services.mozilla.com/D84222
Historically, the MediaThreadType::PLAYBACK was used just for that; the MediaDecoderReader and exclusively for playback content.
This is no longer the case ; it's used in multiple places, and not just with playback: webrtc, webaudio, benchmark etc.
The primary use of the "PLAYBACK" thread was to distinguish from the "PLATFORM_DECODER" one as they dispatch synchronous tasks from one to the other, and we must ensure they don't share the same threadpool.
CONTROLLER is more fitting here, as this is how it's typically used: a controller thread manage the decoder threads.
Additionally, we remove the MTG_CONTROL one as it's not used.
Differential Revision: https://phabricator.services.mozilla.com/D85543
Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
Rename PostTask methods into Dispatch to be more in-line with the current naming convention as PostTask pretty much always referred to the MessageLoop's method.
Differential Revision: https://phabricator.services.mozilla.com/D82159
Ths helps not having to worry about how to create the thread; which could be probablematic when running off a thread pool.
Differential Revision: https://phabricator.services.mozilla.com/D82142
Rename PostTask methods into Dispatch to be more in-line with the current naming convention as PostTask pretty much always referred to the MessageLoop's method.
Differential Revision: https://phabricator.services.mozilla.com/D82159
Ths helps not having to worry about how to create the thread; which could be probablematic when running off a thread pool.
Differential Revision: https://phabricator.services.mozilla.com/D82142
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
When the default sink (sink-id equal to an empty string) has been requested, null device-id is returned. The device-id is propagated all the way down to cubeb. When cubeb is configured with null device-id the default device is chosen. In addition to that, on default device change the new default will be followed. This aligns with the expected behavior for the default sink.
Differential Revision: https://phabricator.services.mozilla.com/D77810
Removed "media.navigator.audio.full_duplex" pref
It was related to `MediaEnginePrefs::mFullDuplex` which wasn't used too, so the according code has been removed
Differential Revision: https://phabricator.services.mozilla.com/D75993
Narcis Beleuzu
Jan-Ivar Bruaroey
Karl Tomlinson
Agi Sferro
Nathan Froyd
Andreas Pehrson
Mike Conley
Bogdan Tara
Jean-Yves Avenard
Coroiu Cristina
Emilio Cobos Álvarez
Paul Adenot
Simon Giesecke
Alex Chronopoulos
Anny Gakhokidze
Sylvestre Ledru
Corentin Arnould