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.4.0 : Friday, 17 January 2020 19:17:58 UTC