Re: Update of Doohickey/AddTrack proposal

On 2014-02-11 22:04, Harald Alvestrand wrote:
> 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.

By simply moving to adding tracks, but still signal MediaStream info, we 
suddenly involve all streams a track is a member of. Instead of 
simplifying I think we're going in the opposite direction.

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

I guess it should. A change could have impact on what media is rendered 
on the receiver side (if it concerns a used MediaStream). In other 
cases, the sending side may be doing something with a stream that used 
for local recording and has nothing to do with what's being sent.

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

By "use" I, e.g., mean render. If a track is received, and it has info 
(from the sending side) that it belongs to five different MediaStreams. 
Which MediaStream should the receiving side render? It clearly needs app 
specific info from the sender side.

/Adam

Received on Wednesday, 12 February 2014 12:56:10 UTC