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
This lets us notify about a created TrackUnionStream track (and since it was
created, we can notify when it ends), even though it has been blocked from main
thread.
MozReview-Commit-ID: HyopzISBfbb
--HG--
extra : rebase_source : a18be6b0fcb194c016ae06c62eb5cebbf86eb8d5
extra : intermediate-source : 38e3e48c8dd011a0503f1241c7b21a630738c6c0
extra : source : 690904309e169aa74f95163f0d796493ef882972
Rename those two function to better name alignment with AddDirectListener and AddDirectTrackListener.
MozReview-Commit-ID: 6QY08oyih1X
--HG--
extra : rebase_source : e0f2ac5de75d54a870f5a99f08505e40aa0696d9
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 : af67b8f8e0dfc340d50af7bcfe8e476159cefeac
extra : source : dbb4b83be583eacc401648c5c33091958c29c4c3
This lets us notify about a created TrackUnionStream track (and since it was
created, we can notify when it ends), even though it has been blocked from main
thread.
MozReview-Commit-ID: HyopzISBfbb
--HG--
extra : rebase_source : a3d676257473bba08190b8e2b24d027c42306621
extra : intermediate-source : 5454dcaa31ff8eb060b6f1531a376dcbc24ffb4d
extra : source : 690904309e169aa74f95163f0d796493ef882972
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 : 81c7b6356e5f43b39b1c3fd9c70e14059cae7e63
This lets us notify about a created TrackUnionStream track (and since it was
created, we can notify when it ends), even though it has been blocked from main
thread.
MozReview-Commit-ID: HyopzISBfbb
--HG--
extra : rebase_source : 55d6dd5d6a34a0b499b45e0b72f900fc37cff1bf
extra : source : 690904309e169aa74f95163f0d796493ef882972
