I hit this during local tests. It's a fine invariant but it doesn't hold in
forced shutdown.
MozReview-Commit-ID: HtoiGwf7IMI
--HG--
extra : rebase_source : 707de2fe08ccad99a06dab00969e2f140e63abad
With the added invariant that NotifyPull() needs a MediaStreamListener present
to not underrun, we need SetPullEnabled() and AddListener() to stay in sync by
using the same signaling mechanism.
MozReview-Commit-ID: 49KWdiTOG98
--HG--
extra : rebase_source : d0ad44d7ce431aa792c4908f96baf0c0920dbe90
This modifies mediaCaptureWindowState() to say whether a camera or microphone is
actively captured or not. Note that this is not the same as the device being
on or off. If we disallow a device from being off while disabled, we still
notify chrome that we're not actively capturing.
MozReview-Commit-ID: B1taormqc3j
--HG--
extra : rebase_source : 292d323c4b9711cc242170f5c5c139bb87658c44
This wires up the disabling of a track with actually stopping the device if we
allow it.
This is possible for:
- Camera (enabled by default, controlled by pref
"media.getusermedia.camera.off_while_disabled.enabled")
- Microphone (disabled by default, controlled by pref
"media.getusermedia.microphone.off_while_disabled.enabled")
Screen-, app-, or windowsharing is not supported at this time.
On disabling, there's a delay before the device is ordered to stop. This is
now defaulting to 3 seconds but can be overriden by prefs
"media.getusermedia.camera.off_while_disabled.delay_ms" and
"media.getusermedia.microphone.off_while_disabled.delay_ms".
The delay is in place to prevent misuse by malicious sites. If a track is
re-enabled before the delay has passed, the device will not be touched until
another disable followed by the full delay happens.
MozReview-Commit-ID: D4nZWzrYZGm
--HG--
extra : rebase_source : 6a54fa450bd435ed65de2a30b66d25f4a5e8241e
This is the larger change for this bug. In order to turn off a device on
disabling we want to Stop() it without ending the attached track.
To allow this, this patch breaks out track-creation from Start() to SetTrack()
and moves track-ending logic from Stop() to Deallocate().
It is a programming error to Start() or Stop() a MediaEngineSource that hasn't
seen a SetTrack().
MozReview-Commit-ID: 3KzmuDjCAH0
--HG--
extra : rebase_source : 361d9b9c2a818ce51fa90d88950d5992c51407c6
The scope of flattening this hierarchy quickly grows large, so this patch does
a couple more things:
- Creates a pure interface MediaEngineSourceInterface and a base class
MediaEngineSource with common defaults and refcount support (no state!)
- Breaks out some of the helper classes to dedicated files, e.g.,
AllocationHandle, MediaEnginePrefs.
- Clarifies the threading model (written on one thread *and* under lock,
read under either)
- Fixes style, indentation, include-sorting in the affected files
- Adds comments, especially for clarifying what responsibilities methods have,
and thread usage of class members
- Changes Monitors to Mutexes since we only use them as Mutexes anyhow
- Makes MediaEngineRemoteVideoSource no longer a shared source since we now
support scaling in this source and CamerasChild can act as a broker of frames.
This greatly simplifies it. The only shared source is now
MediaEngineWebRTCMicrophoneSource, so the sharing specific common methods have
been moved to that source.
MozReview-Commit-ID: KeVZQo6gLm2
--HG--
rename : dom/media/webrtc/MediaEngine.h => dom/media/webrtc/MediaEnginePrefs.h
extra : rebase_source : c785a5feb896312912170475d6b8d997e712e48f
There are legit cases when a SourceMediaStream gets pulled without a listener
present.
A clear example (though a corner case and easily overlooked) that I've hit is
when the last track is ended and the only stream listener is removed at the same
time. This leads to a pull on the next iteration where the track-end has not
yet been picked up. And thus, a false positive error saying that a live track
doesn't have listeners.
The real error here will now instead be caught by the new assert for when a
pulled stream underruns (which is now illegal).
MozReview-Commit-ID: 3e8FcCZfhYJ
--HG--
extra : rebase_source : ada823dbab07c8ca50429cd854b0c4b1df688fbb
This SourceMediaStream is an existing hack to fit AudioCapture into
MediaManager's gUM flow. With the invariant that NotifyPull must produce data
we need to produce silence here.
Best of all would be if this SourceMediaStream was not needed at all, but let's
look at that another time.
MozReview-Commit-ID: J3EeIut1fgy
--HG--
extra : rebase_source : 8b84d8cf0f8d359d3b1c054146b28d494ed12053
In the MediaEngine for microphone capture we want to fall back on feeding
silence when the device is stopped. To ensure this doesn't go haywire we check
that the invariant that at most one of NotifyInputData and NotifyPull get
called in the same iteration.
For them to be aligned on which iteration they're in however, the graph needs
to report a consistent IterationEnd() to both. This patch fixes this by only
calling into NotifyInputData() *after* setting iteration state, which will then
be consistent also across OneIteration (which calls into NotifyPull).
MozReview-Commit-ID: 4lD4OcdGtM6
--HG--
extra : rebase_source : 397ee320b83b23ac21961b67341b774f18e8b51b
This allows MediaRecorder to pass non-empty blobs to content since our
blob gathering code waits for a new keyframe before writing to the blob.
--HG--
extra : rebase_source : be52d34df5c6b4d40d4b445c6d3ae0036e1c6904
extra : histedit_source : 43b2cf01b335a37f04032545fc9965bf574657ee
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
The changes to the cubeb API mean that the new prefs member on
cubeb_stream_params should be explicitly set. This changeset does so.
MozReview-Commit-ID: 1hwjLTriaBP
--HG--
extra : rebase_source : f32c4a0a945ed7a048ca40c7286024da1fb93473
Around every Firefox update, Netflix see a spike in
MediaKeySystemAccess.createMediaKeys() promise rejects. I am wondering whether
this is caused by the browser restarting to apply a Firefox update while
Netflix's player is loading. So add more detail to the promise reject as to
the state of the system, to try to validate that theory.
MozReview-Commit-ID: 4IDPsFwKCtq
--HG--
extra : rebase_source : 0a53acb623f895e598845c281edc73b926c74c28
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
