This allows removing locking, and allows other threads to progress without
taking the lock, hence lowering the probability that the lock will be taken for
a long time when we need to pull NeqEQ.
MozReview-Commit-ID: HMO67A0hher
--HG--
extra : rebase_source : aa5c77895eb57d60b61d9a8a5822e53593348830
We made NotifyPull parallel to try to lower the load, and we initially measured
an improvement. However, we did the measurements with a profiler that did an
aggregation of the results. Our results had an high variance, so the mean load
was in fact not meaningful.
More careful measurement performed without doing any aggregation show that,
under load, relying on the fact that the scheduler schedules the tasks on time
is too risky, and that the code is fast enough to not have to parallelize.
MozReview-Commit-ID: CMhSn8Sc0OO
--HG--
extra : rebase_source : cfb41f861089bce9e10446bee81c13f8565ba90e
This also causes a lot of dropouts. We don't need to lock here. NetEQ is thread
safe, and its created in the ctor. The rest of the members are made atomic or is
simply never accessed in multiple threads.
MozReview-Commit-ID: 2fRw5ZgxdpQ
--HG--
extra : rebase_source : f2aa082a3e856e873cfcd96ff721ccdc77df3633
This accounts for half of our audio dropouts, there is very high contention on
this piece of data.
MozReview-Commit-ID: 2HSfqZHT2MK
--HG--
extra : rebase_source : 10c451ac60563a0f1c14a314f5a12cc45055e20b
This pulls in the fixes to shutdown RPC channels correctly when all
client proxies are dropped. This stops leaking fd and shmem.
MozReview-Commit-ID: 8Kb0iFPn8Pc
--HG--
extra : rebase_source : 8fcce9dfbec570f4d3ec035a6dd6576d1d137cd5
This hard codes the visual studio version to 2015. We did the same thing for the
gyp build. It also sets default paths for visual studio, which are ignored by the
remainder of the build system.
This was required to get gn code generation working on a fresh install of
Windows. I must have had similar changes on my old Windows VM but missed
commiting them as part of the gyp to gn build switch.
MozReview-Commit-ID: 7fYngpdIwxh
--HG--
extra : rebase_source : de24b50f8e19465d8c145ce96c31d4ad7cc52e57
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
A minimized window has a resolution of 1x1. Although we removed minimized windows from the list
of available windows to share, nothing prevents the user from minimizing it during a call. With
the current code, this will cause InitEncode to fail, resulting in a fatal release assert.
I tested this patch with window sharing on meet.google.com and I was able to minimize and restore
the window several times without problem. While minimized, the window appears as a black screen
to the other meeting participants. It renders normally when restored.
MozReview-Commit-ID: LE2NBiEy8nw
--HG--
extra : rebase_source : f95fd3f797e9f7262a938087ce3fb1e27f743920
It is written under lock on the controlling thread (CamerasParent) in
StartCapture/StopCapture.
MozReview-Commit-ID: E7eq1YElhwt
--HG--
extra : rebase_source : f37b666d84c6710ac0d5c56002b82c707635f49b
If we stay in the critical section, and the StartCapture() is a reconfiguring
one, we risk deadlocking with IncomingFrame which runs on the camera thread.
MozReview-Commit-ID: 5rU4urrBWxr
--HG--
extra : rebase_source : 4c6e0c1e02eb1116a1fe433681bf4ad36f47186a
Looper lifetime must be handled by external callers as otherwise internal
callers may accidentally and unknowingly quit the looper and essentially
terminate the camera thread, stopping any flow of frames and preventing future
messages.
In this case, a reconfig of the capture settings through startCapture() causes
startCaptureOnCameraThread() to restart the capture by calling into
stopCaptureOnCameraThread() (quitting the looper) and then re-calling
startCaptureOnCameraThread() (not restarting the looper as that is invalid).
The camera thread is set up by startCapture() on the external calling thread,
which will never know that a seemingly graceful camera thread operation stopped
the camera thread altogether, and so it cannot take any action.
MozReview-Commit-ID: DUTFdanTan1
--HG--
extra : rebase_source : afeb80aa8b2596a2615f57ec4af182a837323b7e
This limits screensharing simulcast to a single layer. When window sharing, our
source video can have arbitrary dimensions. If one of those dimensions ends up
being odd, the aspect ratio of the smaller layer will not match the aspect ratio
of the odd sized layer, causing a runtime assertion failure and crash.
It is not sufficient to prevent the creation of odd sized layers in
CreateEncoderStreams because the user can resize the window while it is being
shared, which will cause a fatal assertion prior to the streams being recreated.
When switching back from window sharing to camera, a call to
CreateEncoderStreams will occur with resolutions matching the dimensions of
the window that was just shared. To prevent a crash, this also adds a check
which prevents the creation of layers with odd resolutions.
Looking at cricket::GetSimulcastConfig for the version of webrtc.org in tree,
the number of simulcast layers is limited to one, or two if a field experiment
is enabled. That code also limits resolutions at which screensharing is allowed
as well as the number of layers that can be created for each resolution, and
ensures that each layer is exactly half the size of the layer above.
Adding these new constraints to CreateEncoderStreams makes us more consistent
with what the webrtc.org code would do when creating streams, which should
help to avoid more assertion failures in the future. Long term, I believe we
should just switch to using cricket::GetSimulcastConfig.
MozReview-Commit-ID: 8gjdY5GPPjl
--HG--
extra : rebase_source : b13b7acdac7f1e0b6016417b83bbe97dc2417a92
This limits screensharing simulcast to a single layer. When window sharing, our
source video can have arbitrary dimensions. If one of those dimensions ends up
being odd, the aspect ratio of the smaller layer will not match the aspect ratio
of the odd sized layer, causing a runtime assertion failure and crash.
It is not sufficient to prevent the creation of odd sized layers in
CreateEncoderStreams because the user can resize the window while it is being
shared, which will cause a fatal assertion prior to the streams being recreated.
When switching back from window sharing to camera, a call to
CreateEncoderStreams will occur with resolutions matching the dimensions of
the window that was just shared. To prevent a crash, this also adds a check
which prevents the creation of layers with odd resolutions.
Looking at cricket::GetSimulcastConfig for the version of webrtc.org in tree,
the number of simulcast layers is limited to one, or two if a field experiment
is enabled. That code also limits resolutions at which screensharing is allowed
as well as the number of layers that can be created for each resolution, and
ensures that each layer is exactly half the size of the layer above.
Adding these new constraints to CreateEncoderStreams makes us more consistent
with what the webrtc.org code would do when creating streams, which should
help to avoid more assertion failures in the future. Long term, I believe we
should just switch to using cricket::GetSimulcastConfig.
MozReview-Commit-ID: 8gjdY5GPPjl
--HG--
extra : rebase_source : 5a22f6d0a995303e6a4039eafc056631fbb86415
Jean-Yves Avenard
Paul Adenot
David Major
Nils Ohlmeier [:drno]
Dan Glastonbury
Andreea Pavel
Dan Minor
Jan Beich
Nicholas Nethercote
Noemi Erli
Coroiu Cristina
Sebastian Hengst
Matthew Gregan
Tom Bannister
Jan-Ivar Bruaroey
Margareta Eliza Balazs
Tristan Bourvon
arthur.iakab
Andreas Pehrson
Narcis Beleuzu
Boris Zbarsky
Byron Campen [:bwc]