- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 29 Apr 2014 09:52:47 +0200
- 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