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
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
