W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2014

Re: Update of RTCRtpSender "doohickey" proposal

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 29 Apr 2014 09:52:47 +0200
Message-ID: <535F5A4F.9060203@alvestrand.no>
To: public-webrtc@w3.org
On 04/29/2014 04:19 AM, Martin Thomson wrote:
> On 28 April 2014 16:51, Justin Uberti <juberti@google.com> wrote:
>> I thought about it a bit, and I don't really see an issue with making it
>> arbitrary. This will put the track to be in the specified MS at the other
>> side, but I don't see a need to force the tracks to be bagged up on the send
>> side.
> Why not just put the stream in, not its identifier and avoid the issue?

Putting its identifier in rather than the stream object has some 
advantages. In particular for the case where you have been sending a 
stream, but for some reason have thrown it away, and want to connect a 
different stream on the sender side to the old stream on the receiver 
side. This would make "rehydration" simpler, I think.

>
> As for the null case, generate a new stream on the remote side for
> every track that is added that way.
>
If the stream object is null, the receiver can choose to add the track 
to an existing stream or to create a stream for it.

If the stream object is an auto-generated stream, the receiver can 
choose to add the track to an existing stream or to use the stream it's 
handed; in the former case, the auto-generated stream will eventually be 
garbage-collected.

In practice, there seems very little difference between the two 
alternatives, but auto-generating a stream lets the receiver skip 
testing whether there's a stream there or not, so I think I like that.
Received on Tuesday, 29 April 2014 07:53:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:38 UTC