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
When switching to the gn build, we accidentally began linking against the
newer webrtc.org avfoundation library rather than the locally patched,
older version. This breaks the ondevicechange event and causes other
problems.
MozReview-Commit-ID: Kz2RBK4xkjQ
--HG--
extra : rebase_source : 8ecd07177cc7de1571133d061faa57bd87a3fe4b
extra : histedit_source : 2a2044c85a28975e40996ef839c6c82926142d51
The original logic I wrote had the condition backwards.
MozReview-Commit-ID: IFIS8vZLgd4
--HG--
extra : rebase_source : 9f9baeb2f6284c551fb63f139d6f5942569890fd
This removes the gyp files to build webrtc. It looks like part of Bug 1371485 is
to vendor gyp elsewhere in tree at which time we can complete cleaning this up.
MozReview-Commit-ID: 8MqatafniN5
--HG--
extra : rebase_source : 1cf7a41f0b8a1a95dc008f4a39536ee7e76027c4
