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

Re: Update of Doohickey/AddTrack proposal

From: Justin Uberti <juberti@google.com>
Date: Mon, 10 Feb 2014 15:24:01 -0800
Message-ID: <CAOJ7v-03m=_Hi+50XKotyn96G+RCCqLbsgHLia=z-zJnT4kE6g@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: Adam Bergkvist <adam.bergkvist@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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

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