Re: Update of Doohickey/AddTrack proposal

On 02/11/2014 02:12 PM, Adam Bergkvist wrote:
> 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 we don't have addStream, the only logical course I see is to create
five MediaStreams, and, if we keep onaddstream, fire five addstream events.

If we keep addStream, the sending PC can know which streams are of
interest, and can signal only those streams.

But we need to have a proposal from the proponents of
s/addStream/addTrack/ on this.

> 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.

As with everything related to signalling, once the signal gets to the
receiver, info will be updated. The real question is whether
negotiationneeded should be fired on the sending side when this happens.

> 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.

What do you mean by "use"?

The track must be added to all streams that it's identified in
signalling to belong to, and no others.

> /Adam

Surveillance is pervasive. Go Dark.

Received on Tuesday, 11 February 2014 21:05:25 UTC