With transport-cc enabled, we get feedback calls into AudioSendStream occuring
on the sts thread. Since AudioSendStream is constructed on the main thread,
this trips up the worker_thread_checker_ checks. The functions that are called
end up doing their work using AudioCodingModuleImpl::ModifyEncoder, which
takes a lock, so it should be safe to remove these assertions.
We've had to do similar things to ChannelProxy in the past to get stats
working from the sts thread. ChannelProxy has been removed upstream, but we
should consider changing our use of AudioSendStream with the next libwebrtc
update so that is always called from the same thread.
Differential Revision: https://phabricator.services.mozilla.com/D72157
To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Differential Revision: https://phabricator.services.mozilla.com/D67631
--HG--
extra : moz-landing-system : lando
TRACE_AUDIO_CALLBACK() and TRACE_AUDIO_CALLBACK_COMMENT(aFmt, ...) log to a hardcoded thread id number. This creates confusion when more than one MTG is running because logs from different threads are depicted to the same thread line and overlapping each other. Those logging commands have been removed and the TRACE* command is used that it logs per thread-id.
Differential Revision: https://phabricator.services.mozilla.com/D69031
--HG--
extra : moz-landing-system : lando
This change includes support to negotiate the transport-wide-cc RTP extension
needed to enable sender side bandwidth estimation in WebRTC. When this
extension is supported in both sides during the Offer/Answer negotiation the
transport_cc mode is enabled in the WebRTC engine so that this mode is used
instead of the legacy receiver-side (REMB based) mechanism.
The change is inspired on this fork by medooze team:
https://github.com/medooze/gecko-dev/pull/2/files
Co-authored-by: ggarber <gustavogb@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D68734
--HG--
extra : moz-landing-system : lando
This essentially implements the "queue a task" step required by the spec, which
ensures that if JS checks stats multiple times without relinquishing the event
loop, it will see the same thing each time.
Differential Revision: https://phabricator.services.mozilla.com/D64468
--HG--
extra : moz-landing-system : lando
Primarily, this removes code that was compensating for inconsistencies between webrtc.org's timestamps, and JS timestamps. Also, this removes a few bits of indirection on GetRtpSources; that's all going to go directly to RTCRtpReceiver now. None of this code is being moved elsewhere.
Depends on D50395
Differential Revision: https://phabricator.services.mozilla.com/D64234
--HG--
extra : moz-landing-system : lando
This means we won't have to re-implement all of our JSImpl workarounds in c++.
Also, rename a variable in a way that made it easier to read this code.
Differential Revision: https://phabricator.services.mozilla.com/D50395
--HG--
extra : moz-landing-system : lando
This essentially implements the "queue a task" step required by the spec, which
ensures that if JS checks stats multiple times without relinquishing the event
loop, it will see the same thing each time.
Differential Revision: https://phabricator.services.mozilla.com/D64468
--HG--
extra : moz-landing-system : lando
Primarily, this removes code that was compensating for inconsistencies between webrtc.org's timestamps, and JS timestamps. Also, this removes a few bits of indirection on GetRtpSources; that's all going to go directly to RTCRtpReceiver now. None of this code is being moved elsewhere.
Depends on D50395
Differential Revision: https://phabricator.services.mozilla.com/D64234
--HG--
extra : moz-landing-system : lando
This means we won't have to re-implement all of our JSImpl workarounds in c++.
Also, rename a variable in a way that made it easier to read this code.
Differential Revision: https://phabricator.services.mozilla.com/D50395
--HG--
extra : moz-landing-system : lando
We're seeing what looks like occasional late callbacks in
VideoCaptureImpl::DeliverCapturedFrame on OS X. When we call stopCapture, it in
turns calls directOutputToNil which should cause any newly capture frames to be
dropped. It is not clear from the existing code or the documentation what would
happen to any frames which are already enqueued. It looks like it is possible
for frames to be delivered on the old queue, which would explain late callbacks.
Differential Revision: https://phabricator.services.mozilla.com/D67486
--HG--
extra : moz-landing-system : lando
In order to be able to change the audio output device, the device id is exposed to the constructor of MediaStreamGraph. Any component that gets/creates an MTG will be able to provide the device id in order to determine the desired output device. If the provided device id is null the default device will be used.
Differential Revision: https://phabricator.services.mozilla.com/D64133
--HG--
extra : moz-landing-system : lando
Simon Giesecke
Byron Campen [:bwc]
Dan Minor
Nico Grunbaum
Brindusan Cristian
Nils Ohlmeier [:drno]
Noemi Erli
Sergio Garcia Murillo
Tom Tung
Andreas Farre
Alex Chronopoulos
J. Ryan Stinnett
André Bargull
Bogdan Tara
Narcis Beleuzu