Hook up an SCContentSharingPicker MVP integration
Categories
(Core :: WebRTC: Audio/Video, task)
Tracking
()
People
(Reporter: pehrsons, Assigned: pehrsons)
References
(Blocks 2 open bugs)
Details
Attachments
(9 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
We already have Pipewire desktop capture using a system dialog. Let's hook up macOS >= 15 similarly, behind a pref, for now. This let's us integrate SCContentSharingPicker without much other patches (e.g. frontend), and provides an avenue for potential uplift into 131.
Assignee | ||
Comment 1•2 months ago
|
||
Assignee | ||
Comment 2•2 months ago
|
||
Assignee | ||
Comment 3•2 months ago
|
||
Assignee | ||
Comment 4•2 months ago
|
||
This case gets hit if the SCContentSharingPicker is cancelled by the user.
Updated•2 months ago
|
Assignee | ||
Comment 5•2 months ago
|
||
Assignee | ||
Comment 6•2 months ago
|
||
If the resolution is smaller than the allocated surface, we crop.
If the resolution is larger than the allocated surface, we reconfigure with a
larger surface.
The allocated surface has the size we told it to have in the
SCStreamConfiguration, in pixels.
If the source is a screen, the size is pretty static. Changing display settings
could affect it.
If the source is a window, the size is initially the size of the window. The
user resizing the window affects the size.
If the source is multiple windows, the size initially seems to be that of the
display they're sitting on. Windows across multiple displays are not captured
into the same surface, as of macOS 14.
Assignee | ||
Comment 7•2 months ago
|
||
No need to update the last frame unless it has changed.
Assignee | ||
Comment 8•2 months ago
|
||
Assignee | ||
Updated•2 months ago
|
Comment 10•2 months ago
|
||
Comment 11•2 months ago
|
||
Comment 12•2 months ago
|
||
bugherder |
Assignee | ||
Comment 13•2 months ago
|
||
We cannot guarantee that the thread it is used on is static, as both the
VideoCapture and DesktopCapture threads can come and go.
Comment 14•2 months ago
|
||
bugherder |
Comment 15•2 months ago
|
||
Comment 16•2 months ago
|
||
Assignee | ||
Updated•2 months ago
|
Comment 17•2 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/cfcdd5339805
https://hg.mozilla.org/mozilla-central/rev/07dd5fcced62
Comment 18•1 month ago
|
||
[Tracking Requested - why for this release]:
We would like to uplift this work (plus the fixes in the two regressions) once it's had more bake time.
Updated•1 month ago
|
Updated•1 month ago
|
Comment 19•24 days ago
|
||
FWIW, if this is going to go to ESR128, it'll need a rebased patch stack to do so. I'm also not super thrilled about taking this large of a set of changes there, so more explanation as to why it's necessary would be appreciated.
Assignee | ||
Comment 20•24 days ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #19)
FWIW, if this is going to go to ESR128, it'll need a rebased patch stack to do so. I'm also not super thrilled about taking this large of a set of changes there, so more explanation as to why it's necessary would be appreciated.
This is mainly to avoid the new system alerts in macOS 15 that are mentioned in their release notes (see ScreenCaptureKit Deprecations). There's some code in here affecting the existing desktop capture framework, but note most of it is behind a pref and a macOS 15 runtime check. We also would like this to have more time to bake in release before uplifting.
Updated•20 days ago
|
Description
•