- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Mon, 18 Mar 2013 15:47:22 +0100
- To: "public-media-capture@w3.org" <public-media-capture@w3.org>
Hi
As the spec is currently written, the MediaStream() constructor and the
addTrack() method create a new MediaStreamTrack instance to represent a
given track argument. Some of the changes we done lately, like removed
the ordered track list attributes, have made this API harder to work with.
Independent track instances (or clones) are useful to control the output
to different consumers. In the case below, the self-view will show video
but the video to the other peer is disabled.
var peerStream = new MediaStream(selfViewStream); // clone the stream
pc.addStream(peerStream);
peerStream.getVideoTracks()[0].enabled = false;
selfViewStream.getVideoTracks()[0].enabled = true;
However, the cloning behavior of MediaStream() and addTrack() causes
some unintuitive API behavior. For example, if we do:
stream.addTrack(track);
Then the following calls won't behave as one might expect.
stream.getTrackbyId(track.id); // is null
stream.removeTrack(track); // is a no-op and won't remove track from
// stream
The instance track is not a part of stream and the new track instance
has a different id. This may also cause confustion if one tries to use
the track reference passed to addTrack() to influence the output of
stream (example below).
stream.addTrack(track); // as above
pc.addStream(stream);
track.enabled = false; // won't disable the output of any track in
// stream
If we take the proposed approach for sync getUserMedia() as an example.
var video1 = new VideoStreamTrack(constraints1);
var video2 = new VideoStreamTrack(constraints2);
var stream = new MediaStream([video1, video2]);
The instances video1 and video2 are pretty much useless since new track
instances are created when the stream is constructed. It's also not
obvious which video tracks in stream that correspond to video1 and
video2, since the track order is undefined. The proposed sourceId would
make the pairing easier, as long as we keep the restriction that only
one track can represent a source in a MediaStream.
I think the API would be more intuitive if MediaStream() and addTrack()
"adopted" the track arguments instead of cloned them. Cloning would then
be an explicit operation.
To still support cloning, we could either support cloning of both tracks
and streams or simply only tracks.
var clonedStream = stream.clone();
A stream clone can be created by adding cloned tracks to a new stream.
var tracks = stream.getAudioTracks().concat(stream.getVideoTracks());
var trackClones = tracks.map(function (track) {
return track.clone();
});
var streamClone = new MediaStream(trackClones);
What do people think about this?
BR
Adam
Received on Monday, 18 March 2013 14:47:50 UTC