If listeners are still registered to a MediaStream on MediaStream::Destroy
(triggered by MediaStream::UnregisterUser below), they will catch and act
on further events from the MediaStream (such as a track ending).
This may dispatch runnables that are unnecessary since we know we are
shutting down.
If we first remove the listeners from the MediaStream we will never see
said events.
MozReview-Commit-ID: IZ1kENqL2C8
--HG--
extra : rebase_source : 6f9201827a30f119b4c116d0cb798858408aed20
We have different concept of "finish" between the base class and its hierarchy.
Attempt to clear the sitatuation by renaming the members and related methods.
MozReview-Commit-ID: vFsXhMK5GY
--HG--
extra : rebase_source : 65eda9257e447584161da51af7c240e31027c501
It doesn't matter that this is traversed by the cycle collector when the track is live and playing.
It prevents cycle collection of any number of MediaStreams that contain (thus consume) this track.
MozReview-Commit-ID: GvdLfWDTVQQ
--HG--
extra : rebase_source : 29e65d25bd7cdf03e32ff4aa736b0ff762ebf1c1
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
For testing purposes, it is useful to pass a null aWindow to the DOMMediaStream
constructor. This limits the amount of code that needs to be mocked to create
a mock media stream.
MozReview-Commit-ID: Jgm1m7N0FU4
--HG--
extra : rebase_source : 90ab0157bd0d75cb53190bf4a5d388971a6fdd1b
This patch is adapted from Tor bug 1517.
To offer some protection against timing attacks by JS content pages, in this
patch we round the various time-exposing APIs (such as Date and
Event.timeStamps) to the nearest 100 ms when the pref "privacy.resistFingerprinting" is on.
MozReview-Commit-ID: eGucM9nGTn
--HG--
extra : rebase_source : 3ee600b07943f3954e9a2a9561391f2f7821bb86
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
Better semantics for what I want to do with NotifyEnded in later patches in the bug.
MozReview-Commit-ID: 8X0BdiVncNo
--HG--
extra : rebase_source : f36f5a17f2294c6ad9b5db2593b41eb8cd8a9a15
The new name makes the sense of the condition much clearer. E.g. compare:
NS_WARN_IF_FALSE(!rv.Failed());
with:
NS_WARNING_ASSERTION(!rv.Failed());
The new name also makes it clearer that it only has effect in debug builds,
because that's standard for assertions.
--HG--
extra : rebase_source : 886e57a9e433e0cb6ed635cc075b34b7ebf81853
Turns out runnables added through
MediaStreamGraph::DispatchToMainThreadAfterStreamStateUpdate on the same
iteration are all run in the same task. Creating them in the owning dom stream
in one task solves the timing issues and lets us add them
(and raise "addtrack") in individual tasks.
MozReview-Commit-ID: 9Q3NoFrmnQs
--HG--
extra : rebase_source : aa391668ec424d2f9b1485f6218d7d1f9948abc9
This adds support for HTMLMediaElement.mozCaptureStream() and
mozCaptureStreamUntilEnded() for a HTMLMediaElement playing a MediaStream.
This is up to spec, while capturing a HTMLMediaElement playing a file is not.
This incompatibility means we cannot mix sources for the returned MediaStream.
As such, a MediaStream returned while the HTMLMediaElement was playing a file
will only have content while the element is playing files. If the src changes
to a MediaStream, the stream will be empty.
It works the same way if a MediaStream was captured while the HTMLMediaElement
was playing another MediaStream.
This is due to TrackID management - MediaDecoder doesn't care, and creates new
tracks when you seek, so users are unable to keep track, while for MediaStream
we control everything from main thread and keep track of the TrackIDs used
previously.
This also adds a separate path from MediaElementAudioSourceNode so that we don't
forward video tracks when the returned MediaStream is only used internally for
WebAudio. We should in that case not require a DOMMediaStream but just forwarding
tracks to a TrackUnionStream should be enough, and will save us some cpu cycles.
This is however fine for now as it's simpler.
MozReview-Commit-ID: Bg8hESDISDU
--HG--
extra : rebase_source : 83885a73ec8cfc5fbe3c30a9330a52cd6b6dff12
extra : source : f1aec79078869c0a6435a1c06957c649d7a40dd9
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
This can reduce the include header dependency. MediaStreamVideoSink will inherit from DirectMediaStreamTrackListener. But we can't use forward declaration on MediaStreamListener because the usage of nsTArray<RefPtr<MediaStreamVideoSink>>.
MozReview-Commit-ID: 328s4Kw9NvW
--HG--
extra : transplant_source : %D2%18%E3%3B%0C%D8%F04%F3%EB%EB%A0%A7%8B%B1%A9%AB%97rY
Rename those two function to better name alignment with AddDirectListener and AddDirectTrackListener.
MozReview-Commit-ID: 6QY08oyih1X
--HG--
extra : transplant_source : %5C%1C%23%AC%D7%0D%97%24%CB%ED%8E%D5%60/%5E%07%F2%85Z%DA
After ending the MediaInputPort (to the playback stream) gets removed if locked
to the track specifically. Trying to remove the track at this point would try to
block it in the same MediaInputPort - but since it doesn't exist would trigger
an NS_ERROR instead.
MozReview-Commit-ID: IpRL6FAGxPp
--HG--
extra : rebase_source : 7fea1d440c8e03911861acd64323083944591f0e
extra : intermediate-source : aa209325161f45a5607982af76ef1784208690a5
extra : source : dbb4b83be583eacc401648c5c33091958c29c4c3