This so that SourceListener can keep its internal state in sync with the result
of the start operation.
MozReview-Commit-ID: Cgl5TFnpCeW
--HG--
extra : rebase_source : 4a7e8c1217b0db3879312d4b33dc74227e969608
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
Currently we run the risk of missing MediaManager::OnNavigation() at shutdown in
some cases. When it happens, cleanup of window listeners is delayed to
MediaManager::Shutdown().
Triggering window listener shutdown through the destructor doesn't work when the
destructor is invoked by WindowTable::Clear(), as clearing out the
window listener's SourceListeners will trigger a call back into
WindowTable::Remove() to remove the now empty window listener.
This is not allowed by the hash table implementation.
This patch fixes this by changing strategy from cleanup-in-dtor to explicit-cleanup-before-dtor and making a non-clean state in the dtor an error.
MozReview-Commit-ID: C9FryVlv28d
--HG--
extra : rebase_source : 55ccf96b15eb3261d5176364e6952f51415bc668
This delays setting sInShutdown (renamed to sHasShutdown for better semantics)
until all that remains of shutdown is to shut down the media thread.
From JS this is no change as JS cannot run until Shutdown() is done.
The difference is that we let members and still-active listeners get destroyed
and cause any members that are media-thread only (in this case devices), to shut
down before the thread goes away.
MozReview-Commit-ID: 5NTWwh8Umn8
--HG--
extra : rebase_source : f6b508abc95434f027a6544fdac53949138764da
These were originally exposed directly as static methods on nsGlobalWindow, but
as they are clearly associated with either the inner or outer window, it makes
more sense for them to be called as such.
MozReview-Commit-ID: LFq8EfnhDlo
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
The NS_LITERAL_STRING macro creates a temporary nsLiteralString to encapsulate the char16_t string literal and its length, but AssignLiteral() can determine the char16_t string literal's length at compile-time without nsLiteralString.
MozReview-Commit-ID: 6vgQiU8zN3o
--HG--
extra : rebase_source : 1b536b92ef43f610db057ace6f108620e8d8b4d5
extra : source : 336e21386d5eeb16f1c9893c29377f23b67cc4b0
XPCOM's string API doesn't have the notion of a "null string". But it does have
the notion of a "void string" (or "voided string"), and that's what these
functions are returning. So the names should reflect that.
--HG--
extra : rebase_source : 4e3f982e0873877174a08a25413595ff66f7d20e
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
As well as the obvious #ifdefs, this allows DOMHwMediaStream to be
removed, and also the "phone-state-changed" observer.
--HG--
extra : rebase_source : 373280183e228bd4b9bd9d866959409f2444c77e
Right before `MediaManager::EnumerateRawDevices` posts its enumeration
task to the background thread, add the option to send out a
"getUserMedia:ask-device-permission" notification, whose purpose is to
give frontend UI a chance to ask for device permissions (e.g. permission
to enumerate cameras on Android).
The subject parameter of the notification is an `nsIRunnable` task,
which is passed back to `MediaManager`, after receiving permission,
through the `getUserMedia:got-device-permission` notification. The
notification listener then posts the task and enumeration proceeds as
before.
MozReview-Commit-ID: IhRXTdIplvN
This in large does the following:
* Changes the model in MediaManager to align with that of chrome code, namely:
- One GetUserMediaWindowListener *per window*, containing N SourceListeners for N gUM requests, and
- GetUserMediaWindowListener replaces GetUserMediaStreamListener
- So if two SourceListeners stop we can still send only one event
* Breaks a special event specific to B2G chrome
MozReview-Commit-ID: 3wbPFmc9yWj
--HG--
extra : rebase_source : dff76a1fa604962b45446d632ffb4da58853cfa0
This in large does the following:
* Changes the model in MediaManager to align with that of chrome code, namely:
- One GetUserMediaWindowListener *per window*, containing N SourceListeners for N gUM requests, and
- GetUserMediaWindowListener replaces GetUserMediaStreamListener
- So if two SourceListeners stop we can still send only one event
* Breaks a special event specific to B2G chrome
MozReview-Commit-ID: 3wbPFmc9yWj
--HG--
extra : rebase_source : 4ad324f6bb1be637da584f323a3e039c5b4f664d
This in large does the following:
* Changes the model in MediaManager to align with that of chrome code, namely:
- One GetUserMediaWindowListener *per window*, containing N SourceListeners for N gUM requests, and
- GetUserMediaWindowListener replaces GetUserMediaStreamListener
- So if two SourceListeners stop we can still send only one event
* Breaks a special event specific to B2G chrome
MozReview-Commit-ID: 3wbPFmc9yWj
--HG--
extra : rebase_source : 4ad324f6bb1be637da584f323a3e039c5b4f664d
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
They are not unstoppable any longer. We just don't forward Stop() to the real source.
MozReview-Commit-ID: FdFccMsD3eb
--HG--
extra : rebase_source : e29a1abb8f2060cb72399d61d91ca3a00128f08c
MediaStreamTrack.remote is no longer part of the spec.
MozReview-Commit-ID: BgHJ1zNIoWN
--HG--
extra : rebase_source : 11022eb420cbdb0c7aa5aa7814cf35330f4170b9
If content stops multiple gUM tracks in the same event loop we should only
notify chrome once to avoid unnecessary chrome updates.
MozReview-Commit-ID: 93aAPUvydPt
--HG--
extra : rebase_source : 685a842acce4970df9a495af1d7fac267b3d252b
extra : source : ed8face75a4664fa11eb64c62a289adf5bcca6db
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
This removes the rest of the usage of nsISupportsArray in MediaManager.
MozReview-Commit-ID: EqXTRNyKiva
--HG--
extra : rebase_source : e41488b4ef7bc6a380a12aae402029d56c92c925
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
--HG--
extra : rebase_source : a8beed043989f6e69e89d17c0db1864c6d7258ac
Sometimes a track is added to a stream synchronously (before the stream is
exposed to script), and sometimes asynchronously (see the mediacapture-main spec
on the "addtrack" event).
In the latter case we might still need to create the MediaStreamTrack object
synchronously for tracking purposes. CaptureStream of Media element playing a
MediaStream wants this.
MozReview-Commit-ID: 7me8xzN7rwj
--HG--
extra : rebase_source : 4f129b127b855e47aad2ae9ab3981ffde057412d
