- From: Justin Uberti <juberti@google.com>
- Date: Mon, 10 Feb 2014 15:24:01 -0800
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: Adam Bergkvist <adam.bergkvist@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAOJ7v-03m=_Hi+50XKotyn96G+RCCqLbsgHLia=z-zJnT4kE6g@mail.gmail.com>
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). On Mon, Feb 10, 2014 at 9:01 AM, Harald Alvestrand <harald@alvestrand.no>wrote: > On 02/10/2014 03:01 PM, Adam Bergkvist wrote: > > On 2014-02-06 19:31, Harald Alvestrand wrote: > >> On 02/04/2014 02:13 PM, Adam Bergkvist wrote: > >>> Hi > >>> > >>> How should we proceed with this proposal? I don't think we will gain > >>> as much when it comes to simplicity if we just remove addStream(), but > >>> keep the concept of tracks belonging to a MediaStream when they are > >>> sent over an RTCPeerConnection (as Stefan argues in a branch of this > >>> thread). That was at least what I had in mind when I argued against > >>> addStream() in [1]. > >> > >> I think communicating the stream concept (which streams exist that have > >> this track as part of it) is important; if we don't communicate it, it's > >> impossible to reconstruct the streams on the receiving side. > > > > Just because *we* don't signal it, doesn't mean that such information > > can't be sent (if necessary for the app). Simple (and legacy > > compatible) apps would perhaps use a single stream for all incoming > > tracks, and multi MediaStream apps could signal a list of track id's > > that makes up a MediaStream. > > > > Which streams exist and what tracks they contain is subject to change. > > If that's something we want to reflect to the other side then that > > could involve a lot of signaling (that needs to be specified but could > > be made easier if it was app specific). > > This would mean abandoning the current feature that you can set up a > connection without signallling anything but the messages made by > CreateOffer/CreateAnswer. > > I thought we had finished that debate 1-2 years back. > > > > -- > Surveillance is pervasive. Go Dark. > > >
Received on Monday, 10 February 2014 23:24:56 UTC