Re: Update of Doohickey/AddTrack proposal

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 

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.


Received on Tuesday, 11 February 2014 13:13:14 UTC