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

Re: New issue: switching sources

From: Peter Thatcher <pthatcher@google.com>
Date: Tue, 20 May 2014 09:01:05 -0700
Message-ID: <CAJrXDUE+wiGjyJ3wSSoKai7O=FZJcYxFaUi1=hYWfkS0XKy=MA@mail.gmail.com>
To: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Jim Barnett <1jhbarnett@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Actually, I think that rather than have .track be settable, we ought to
have a .setTrack() method, since it gives a lot more flexibility.  We can
add a callback if needed, but I don't see the need for one.

I would say that it does not do any new SDP O/A.  It just uses the new
track of media with no changes to negotiation or transport.


On Tue, May 20, 2014 at 8:41 AM, Stefan HÃ¥kansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 20/05/14 17:00, Martin Thomson wrote:
> > On 20 May 2014 07:27, Peter Thatcher <pthatcher@google.com> wrote:
> >> What do you mean by "understand the dangers"?  What dangers are there?
> >
> >
> > Like the one where you have negotiated codec X and you switch in a
> > stream that is attached to a hardware encoder with only codec Y.
>
> So we'd need to spec what happens in that case if you set
> RTPSender.track to the new stream. Error event? Do we design the setting
> of track to have success and failure callbacks? Will a new SDP O/A be
> initiated? etc.
>
> >
> >
>
>
Received on Tuesday, 20 May 2014 16:02:14 UTC

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