This removes the one second timeout for MSG collection, extending the timeout
period to the 50 second timeout of nsMemoryReporterManager.
Also removed:
* The condition variable logic that can stop waiting without checking the
condition set when memory reports are complete.
* Races with mAudioStreamSizes modification on two threads after wait timeout.
Memory from streams in offline graphs that are not yet running is now also
included.
MozReview-Commit-ID: FkI61iJFrZ5
--HG--
extra : rebase_source : 200d332165ef21497bcfa24b86b6ff029f8ac212
This will permit allowing the main thread to run while collecting
reports from graph thread objects.
MozReview-Commit-ID: 7xChGz7xJ8M
--HG--
extra : rebase_source : a69dd197bfd3173c9a46979bac35e654d7d0771e
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
This means that when a MediaStreamListener is added to a stream, we'll call
NotifyQueuedTrackChanges with TRACK_EVENT_CREATE for all tracks that already
exist.
Likewise, we'll call NotifyQueuedTrackChanges with TRACK_EVENT_ENDED for all
tracks that exist and have ended.
This fixes potential race conditions where a track was created and/or ended
before the listener was asynchronously added.
MozReview-Commit-ID: G3juhfiZMtg
--HG--
extra : rebase_source : d2ca7cb24ce154c4aa342bb477aee455c9cfef92
extra : intermediate-source : 80443106b2636d8de3c3de44f2706e99d70c06ae
extra : source : 70e8c5a785a9866e6205b54bd1c45faaf834717d
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
This means that when a MediaStreamListener is added to a stream, we'll call
NotifyQueuedTrackChanges with TRACK_EVENT_CREATE for all tracks that already
exist.
Likewise, we'll call NotifyQueuedTrackChanges with TRACK_EVENT_ENDED for all
tracks that exist and have ended.
This fixes potential race conditions where a track was created and/or ended
before the listener was asynchronously added.
MozReview-Commit-ID: G3juhfiZMtg
--HG--
extra : rebase_source : 4f7b9c116e7d25cfc4c3894551173925613c6c14
extra : intermediate-source : 45bfebd36a99baef6bee50e52ac9c78965a7f1c2
extra : source : 70e8c5a785a9866e6205b54bd1c45faaf834717d
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
This means that when a MediaStreamListener is added to a stream, we'll call
NotifyQueuedTrackChanges with TRACK_EVENT_CREATE for all tracks that already
exist.
Likewise, we'll call NotifyQueuedTrackChanges with TRACK_EVENT_ENDED for all
tracks that exist and have ended.
This fixes potential race conditions where a track was created and/or ended
before the listener was asynchronously added.
MozReview-Commit-ID: G3juhfiZMtg
--HG--
extra : rebase_source : 6f4fe68b888b6dd0d9ee370b6a390ff17da5f1de
extra : source : 70e8c5a785a9866e6205b54bd1c45faaf834717d
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
Rename StreamBuffer to StreamTracks. We still need a place to keep the track information in every MediaStream, even the StreamBuffer::Track::mSegment is empty.
--HG--
rename : dom/media/StreamBuffer.cpp => StreamTracks.cpp
rename : dom/media/StreamBuffer.h => StreamTracks.h
It wasn't clear which TrackID should be passed to MediaInputPort::BlockTrackId(); source or destination.
MozReview-Commit-ID: I9LoSjdpRwE
--HG--
extra : rebase_source : 20eeb5e4ee47eb1cdf00e94cdc72ee11177bbee2
AddAudioTrack() has this comment:
> * Like AddTrack, but resamples audio from aRate to the graph rate.
Even so it would only resample the AudioSegments added through AppendToTrack.
Not the initial one, provided to AddAudioTrack itself, even though
MediaPipelineReceiveAudio depends on this functionality.
MozReview-Commit-ID: BibF9ByjKq3
--HG--
extra : rebase_source : 6de274d0cb76e4eaa39846285dd981c8ba34271b
extra : source : 3eb785084ec7268f3ddee2da3dc78646086bc749
HTMLMediaElement needs special protection when playing a stream since its
ImageContainer can outlive the video track of a stream.
Consider for instance when a (cross-origin) video track is removed from a
DOMMediaStream by a user and the remaining video track (non-CORS) does not yet
contain any actual video frames. The HTMLMediaElement will display a frame from
the removed track but the DOMMediaStream's principal has been updated to not
include the principal from the removed track.
With this patch we handle this by letting VideoFrameContainer notify
HTMLMediaElement when it has flushed out all video frames belonging to a
certain PrincipalHandle. I.e., when a new PrincipalHandle has been applied to the
underlying ImageContainer.
MozReview-Commit-ID: LvIZPl6Rdgj
--HG--
extra : rebase_source : cfbad5e5e7f43af4da4bfc213494b7b8e22cde17
Calculating a principal when adding a track is easy - just combine the new
track principal into the stream's principal.
When removing a track it's a bit trickier. The DOMMediaStream has to wait until
the MediaStreamGraph has removed the track from the underlying playback stream.
We do this by letting the MediaStreamGraph return a Pledge (single threaded
Promise) when blocking a track in a stream (the way we end removed tracks).
The pledge gets passed to the MediaStreamGraph and when the block has been
applied it is passed back to the main thread where it is finally resolved
and the DOMMediaStream may recompute its principal once all outstanding
track removals have been applied.
MozReview-Commit-ID: 3QP0YcDyfGf
--HG--
extra : rebase_source : 6642849ec1c7d774467395dee82b0a37fdd33a99
This lets us know the track's TrackID in the destination stream before
the input port has been processed.
For sanity we only allow mapping to a destination TrackID if the
destination stream does not have any TRACK_ANY input ports already
assigned to it as that can cause intermittent TrackID collisions.
MozReview-Commit-ID: ClFyQl0nYFC
--HG--
extra : rebase_source : 25fa0f34cb4fa9293a572bff03fe005c33be0195