Summary:
The fix for Bug 1409018 accidentally removed saving the current desktop
configuration during Init() which causes it to not be set when a different
screen is selected, meaning that regardless of the choice made, only the
first screen is captured.
Reviewers: pehrsons
Tags: #secure-revision
Bug #: 1487419
Differential Revision: https://phabricator.services.mozilla.com/D5062
--HG--
extra : rebase_source : bb4f9a0f4e06dfbd9730b7af4a0748749d72c3da
Summary:
I think the webrtc.org gtests are the only user of gflags in tree. We can switch
over to using gn to build this when we start building the tests using gn,
which is Bug 1430779.
Tags: #secure-revision
Bug #: 1371485
Differential Revision: https://phabricator.services.mozilla.com/D1802
--HG--
extra : rebase_source : ba496d6f262d3679031f0b933a80ce3e2a2236a5
This defers the call to register the refresh and move handlers to the
CaptureFrame() call so that they will be registered on the ScreenCapture
thread.
This also calls CFRunLoopInMode to process any pending sources in the
run loop corresponding to the ScreenCapture thread so that the
refresh and move notifications are received.
MozReview-Commit-ID: G4aEchnGuUz
--HG--
extra : rebase_source : b74d95015cccb2efa64a711a1824adb379531ca2
This refreshes the gn-generated moz.builds with the change from previous
commit. Somehow, this does unrelated changes, there must be something
funky in the gn-moz.build-generator.
--HG--
extra : rebase_source : 7e1a9d75f7a80c0981b2534e4959ada6c611bae2
This adds a FocusOnSelectedSource method to PCameras and uses it to focus the
selected window while window sharing. We can't just focus the window as soon as
it is shared because we have a live preview in the getUserMedia permissions
prompt which would cause the prompt to lose focus. Instead, this only focuses the
window when the sharing is not done from a chrome context.
MozReview-Commit-ID: 5jre75E3JLi
--HG--
extra : rebase_source : 5f5154fc9fc7590cc02eb25146e5bc20b2243fa3
This adds a FocusOnSelectedSource method to PCameras and uses it to focus the
selected window while window sharing. We can't just focus the window as soon as
it is shared because we have a live preview in the getUserMedia permissions
prompt which would cause the prompt to lose focus. Instead, this only focuses the
window when the sharing is not done from a chrome context.
MozReview-Commit-ID: 5jre75E3JLi
--HG--
extra : rebase_source : 97f472f6ed1c5d6bed1af01fb7243a82b2629b03
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
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 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
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 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
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
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
Original porting was done in bug 807492, so this is mostly gyp->gn translation.
cflags/libs are left unchanged as those aren't used by Gecko.
MozReview-Commit-ID: Bhw6KduoiVm
--HG--
extra : rebase_source : 485f1dfe38106b895ec481444e8a32d08f72f5e7
- If cross-toolchain is N/A use system one instead of error
- BSDs often use Linux interfaces, so don't exclude the files
- Define is_bsd as changes specific to a particular BSD are rare
- Adjust is_clang in case Gecko would use it in future
MozReview-Commit-ID: 5LlCbEKbAPO
--HG--
extra : rebase_source : 68fc72056f65c28d43d2bfb238b26b8895e76ba9
Pause() gave the benefit of another app not being able to steal
the device until the next Run(). It would keep the light on for
some cameras however.
Stop() makes the light go out on these cameras, but put them up
for another application to steal. Basically the same as on our
other platforms.
MozReview-Commit-ID: FPRYcZ2PEpm
--HG--
extra : rebase_source : 1870eb6933b02c83c7e61ac275b648fdde9b4cec
