- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 24 Jun 2015 10:32:17 +0000
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- CC: Martin Thomson <martin.thomson@gmail.com>, Peter Thatcher <pthatcher@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, "Harald Alvestrand" <harald@alvestrand.no>
On 24/06/15 12:17, Silvia Pfeiffer wrote: > > On 24 Jun 2015 5:09 pm, "Stefan Håkansson LK" > <stefan.lk.hakansson@ericsson.com > <mailto:stefan.lk.hakansson@ericsson.com>> wrote: > > > > On 23/06/15 13:07, Silvia Pfeiffer wrote: > > > > > > > > I did some more digging. > > > > > > Reading the spec, I stumble over both an ontrack and an onaddtrack > > > event. The ontrack event is used in Example 4 to replace the > > > onaddstream event from earlier on the RTCPeerConnection. The > > > onaddtrack fires on MediaStream directly. > > > So, we're really talking about the ontrack event here. > > > > Right. > > > > > > > > It seems to me that ontrack has the exact same definition as > > > onaddstream, except it is a RTCTrackEvent (and not a MediaStreamEvent) > > > and can report the addition of multiple MediaStream objects in one go. > > > > > > http://w3c.github.io/webrtc-pc/#idl-def-RTCTrackEvent > > > I'm actually a bit confused about this description: it seems that a > > > track can be part of multiple streams there. That's not how I > > > understand MediaStreams to work - rather, a track would always be part > > > of one stream, but a stream could have multiple tracks. > > > > I think both ways are OK. A MediaStream is basically a collection of > > MediaStreamTrack's, but a MediaStreamTrack can be part of more than one > > MediaStream. > > > > Just assume you have MediaStream's A and B, and a MediastreamTrack X, > > AFAIK nothing forbids > > > > A.addTrack(X); > > B.addTrack(X); > > > > Oh and that doesn't clone the track? Not the way I read http://w3c.github.io/mediacapture-main/#methods > Feels wrong... > > I'm particularly thinking about e.g. A being a stream between two > endpoints X and Y and B being a stream between Y and Z. How can it still > be the same track? I don't think there is anything stopping you from forwarding a track received over one PeerConnection to another endpoint (over another PeerConnection). If the track is identity bound then nothing would come out at Z, but that's another story. > > Cheers, > Silvia. >
Received on Wednesday, 24 June 2015 10:32:46 UTC