Try to get text/uri-list first and then fallback to text/x-moz-url.
text/x-moz-url MIME tends to be poorly supported by third party apps,
we got only one file instead of file list or nothing at all.
Differential Revision: https://phabricator.services.mozilla.com/D231160
Similar to InputStreamHolder, this adds OutputStreamHolder to FetchStreamReader:
1. OutputStreamHolder is not part of the cycle collection but is freed when FetchStreamReader goes away
2. nsIAsyncOutputStream holds OutputStreamHolder which only weakly hold FetchStreamReader, allowing FetchStreamReader to be cycle collected.
3. GlobalTeardownObserver is not added here as we only accept JS ReadableStream here instead of nsIInputStream, which is part of the cycle collection unlike nsIInputStream.
Original Revision: https://phabricator.services.mozilla.com/D233553
Differential Revision: https://phabricator.services.mozilla.com/D233934
Already today we reconfigure capturers without stopping them in cases where they
are shared between multiple gUM/gDM requests: We find the device capability
(for cameras) that satisfies all the requested capabilities (downscaling, frame
dropping allowed) and call StartCapture again with that.
Thus, there is no concern about camera backends not supporting this call
sequence.
Desktop capture backends have a simpler API (only Start, for Stop they have to
be destroyed) and are not actually re-started. Resolution is always captured in
full and frame rate is controlled by the timer that triggers CaptureFrame().
This patch makes content processes not request capture to be stopped when
updating their requested capability. This means the path described above will be
exercised more. This also brings with it some invariants that no longer hold,
but are handled explicitly instead: capabilities for a captureId may now be
updated on the fly, without prior removal.
Original Revision: https://phabricator.services.mozilla.com/D222242
Differential Revision: https://phabricator.services.mozilla.com/D232482
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.
Original Revision: https://phabricator.services.mozilla.com/D221941
Differential Revision: https://phabricator.services.mozilla.com/D232477
This works by creating ScreenCapturerSck with a sck_allow_system_picker
DesktopCaptureOptions flag.
The flow is similar to the Pipewire capturer in that SelectSource has no effect.
Start() brings up the system picker, and:
- automatically starts capture on selection, also reconfigures on future
selection changes.
- signals a stop by setting the permanent error flag on cancel or error.
The system picker is configured for both single display and multiple windows to
give users as much power over what they share as possible. There is an
application mode also, but other browsers are not allowing access to that as of
now.
Original Revision: https://phabricator.services.mozilla.com/D221851
Differential Revision: https://phabricator.services.mozilla.com/D232471
The desktop capture path has no colorspace handling for RGB, and libyuv assumes
sRGB by default. ScreenCaptureKit returns frames in the display's colorspace
unless told otherwise. On modern macs this is 'Display P3' and will render
inaccurately when interpreted as sRGB.
Original Revision: https://phabricator.services.mozilla.com/D220219
Differential Revision: https://phabricator.services.mozilla.com/D232466
The MouseCursorMonitor on macOS is rather expensive, as for every pulled frame
it compares all pixels of the cursors used for the current and last frames.
Getting to the pixels may also incur a conversion.
Note that this comparison happens even if the backend reports it had embedded
the cursor already, as the embedding only affects composing the monitored cursor
into a captured frame.
Original Revision: https://phabricator.services.mozilla.com/D220092
Differential Revision: https://phabricator.services.mozilla.com/D232465
Upstream commit: https://webrtc.googlesource.com/src/+/d4a6c3f76fc3b187115d1cd65f4d1fffd7bebb7c
New macOS screen-capturer which uses ScreenCaptureKit.
This supports:
* Full-screen capture from any display, via SelectSource().
* Changing the display, via SelectSource(), while capture is running.
* Handling screen-resolution changes while capture is running.
* Capturing from high-DPI displays at their native resolution.
* Basic damage-tracking: the frame's updated-region is either set to
empty, or the full frame area.
It currently does not support:
* Window capture.
* Excluded windows.
* Full-desktop capture across all displays.
* More detailed damage-tracking.
The capturer is not yet enabled. Followup CLs will add a
DesktopCaptureOption to enable this capturer on supported versions of
macOS.
Bug: chromium:327458809
Change-Id: Ie619f6c6c1d6edf0fb9320d4fece578754a732dc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/352544
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Cr-Commit-Position: refs/heads/main@{#42510}
Original Revision: https://phabricator.services.mozilla.com/D219808
Differential Revision: https://phabricator.services.mozilla.com/D232457
