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

Re: Update of RTCRtpSender "doohickey" proposal

From: Justin Uberti <juberti@google.com>
Date: Tue, 29 Apr 2014 22:00:05 -0700
Message-ID: <CAOJ7v-0oRua7+9chW8UQi2nOCi=fH1h_moMVzOOchBshSZfc2Q@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Tue, Apr 29, 2014 at 12:52 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

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

In this case, you need to also be able to set the track id as well, which
we don't currently have a mechanism for.

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

Indeed, this makes life simpler for the receiver.
Received on Wednesday, 30 April 2014 05:00:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:55 UTC