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
This allows us to continue adding remaining interfaces from addrs array and
makes sure nr_interface_prioritizer_sort_preference() is called at the end.
Differential Revision: https://phabricator.services.mozilla.com/D66941
--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
It looks like the overload of OnMouseCursorPosition which actually sets the
cursor_state_ member was somehow missed during the last webrtc.org update.
This overload is present in branch 64 upstream, but has subsequently been
removed.
Differential Revision: https://phabricator.services.mozilla.com/D66796
--HG--
extra : moz-landing-system : lando
Enable the NSS workaround introduced in bug 1619102, for DTLS 1.3 WebRTC clients.
Differential Revision: https://phabricator.services.mozilla.com/D66094
--HG--
extra : moz-landing-system : lando
Failing to drop frames if they are cropped to zero width and height leads to
the crash seen in Bug 1521169. We get a call to CreateEncoderStreams
requesting streams with zero width and height at which point it is too late
to do anything, because the webrtc.org code making the call always expects
CreateEncoderStreams to always return at least one stream, and it can't
handle streams with zero width or height.
Depends on D65799
Differential Revision: https://phabricator.services.mozilla.com/D65800
--HG--
extra : moz-landing-system : lando
Also fix AARCH64 build to be neon optimised where available, this leads to a 72% improvement in decoding speed.
Differential Revision: https://phabricator.services.mozilla.com/D64706
--HG--
extra : moz-landing-system : lando
Updating to libvpx 1.8.2 removes one of the structures used for configuring
flexibleMode in the webrtc.org vp9 encoder code. Upstream commit
be71a1ee08c9ee56ba0f92955ea946556ae6593e removes the broken code and at the
same time disables flexibleMode. It remained disabled until commit
76be29555d50f5ec9b5bba1f14588e940e81fd4d landed, three months later. During
that time, a large number of VP9 screensharing fixes were made. It is not
practical to cherrypick all of those changes, so this commit disables
flexibleMode pending the next upstream webrtc.org merge.
This is a partial cherry pick of be71a1ee08c9ee56ba0f92955ea946556ae6593e.
Differential Revision: https://phabricator.services.mozilla.com/D63925
--HG--
extra : moz-landing-system : lando
Byron Campen [:bwc]
Michael Froman
Bogdan Tara
Nils Ohlmeier [:drno]
Matthew Gregan
Dan Minor
Marcin Wojtczak
Sylvestre Ledru
Narcis Beleuzu
Alex Chronopoulos
Kartikaya Gupta
Ed Lee
Kevin Jacobs
Ehsan Akhgari
Noemi Erli
Simon Giesecke
Mike Shal
Jean-Yves Avenard
Nico Grunbaum
Tooru Fujisawa