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
This puts all the logic in GetUserMediaCallbackMediaStreamListener and none in
MediaOperationTask to make it simpler to reason about what's happening.
When we want to stop a track, the gUMCallbackListener will send a
MEDIA_STOP_TRACK if other tracks will still be live.
If it was the last live track, the gUMCallbackListener will send a MEDIA_STOP
instead. The MEDIA_STOP makes sure the passed in devices (we pass in all) are
stopped before finishing the stream.
MozReview-Commit-ID: E43Iqw491tB
Andreas Pehrson
ctai
Kyle Huey
Paul Adenot
Sotaro Ikeda
Randell Jesup
Sebastian Hengst
Daniel Holbert
Nathan Froyd
Birunthan Mohanathas
Phil Ringnalda
Jan-Ivar Bruaroey
Wes Kocher