1918746 - applyConstraints on desktop capture tracks that use a system picker brings the picker up again

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect, P1)

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1918096

Comment 2

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 1918746 - Don't stop video capturers before reconfiguring them. r?#webrtc-reviewers, r?grulja

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.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8f95af75879a
Don't stop video capturers before reconfiguring them. r=grulja,webrtc-reviewers,jib

Comment 4

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/8f95af75879a