- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Tue, 11 Feb 2014 14:12:50 +0100
- To: Justin Uberti <juberti@google.com>, Harald Alvestrand <harald@alvestrand.no>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2014-02-11 00:24, Justin Uberti wrote: > I tend to agree with Harald. There may be other options in the future, > but for now, I think a track needs to signal what stream(s) it is a part > of, so that the simple send-audio-and-video-as-synchronized case works. > > Regardless, I'd like to advance this proposal so that we can start > nailing down any necessary details on the RTCRtpSender/Receiver objects > (AKA doohickeys). > I can see the behavior you want to preserve, but how should it work in practice? Imagine that a RTCPeerConnection gets an incoming track. The track has info that indicates that it belongs to five different MediaStreams. If the track is added to a sixth stream on the sender side, should that be signaled to update the receiver end? Same thing with removal. Out of the five streams, which one should this side use? Other tracks may come shortly that only belongs to a subset of the streams the first track belonged to. It's probably one of those streams I should use, but this becomes quite hard to manage. /Adam
Received on Tuesday, 11 February 2014 13:13:14 UTC