Loading
Bug 1918746 - Don't stop video capturers before reconfiguring them. r=grulja,webrtc-reviewers,jib
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. Differential Revision: https://phabricator.services.mozilla.com/D222242