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

Re: Update of Doohickey/AddTrack proposal

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Tue, 11 Feb 2014 14:12:50 +0100
Message-ID: <52FA21D2.2040302@ericsson.com>
To: Justin Uberti <juberti@google.com>, Harald Alvestrand <harald@alvestrand.no>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
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 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.

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.

/Adam
Received on Tuesday, 11 February 2014 13:13:14 UTC

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