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
The cameraThread is set by startCapture(), so a failed startCapture() that
quits the Looper and runs the cameraThread to completion needs to set
cameraThread back to null for consistency.
Likewise, stopCapture() shall always quit the Looper and set cameraThread to
null.
MozReview-Commit-ID: H1ExLyTixYw
--HG--
extra : rebase_source : 472b657cd8219533a5878f5b268b6288e1fe6320
Pull in fix for cubeb channel layout to PulseAudio channel layout.
MozReview-Commit-ID: L9v3cYM5PAY
--HG--
extra : rebase_source : bc4358efcd6ca6276c242ad3beec7f71288f36d7
Jan Beich
Sebastian Hengst
David Major
Jan-Ivar Bruaroey
Margareta Eliza Balazs
Tristan Bourvon
Dan Minor
arthur.iakab
Andreas Pehrson
Jean-Yves Avenard
Andreea Pavel
Narcis Beleuzu
Boris Zbarsky
Byron Campen [:bwc]
Matthew Gregan
Alex Chronopoulos
Nils Ohlmeier [:drno]
Dan Glastonbury
Tom Ritter
Cosmin Sabou
Nathan Froyd
Bogdan Tara
Paul Adenot