Re: [webrtc-pc] addTransceiver woes

There's something I don't understand about replaceTrack() and "Determine if negotiation is needed" that is keeping me from coming to a conclusion on this issue.

replaceTrack() only works if the replacing track is compatible with the already negotiated codec settings. Correct? ("Determine if negotiation is needed, if it is, reject")

So now, is a track needed for the O/A cycle to include the encoder settings, or will the O/A look the same regardless of chosen track?
- If a track isn't needed, starting with a null track and doing replaceTrack() makes sense.
- If a track is needed, starting with a null track means we do an O/A cycle without deciding what codec setting to use. And doing replaceTrack() would fail because we have yet to negotiate what encoder settings to use.

```
// 1. This works
sender = pc.addTrack(track1);
O/A cycle
sender.replaceTrack(track2);

// 2. What about this?
transceiver = pc.addTransceiver(); // transceiver.sender.track is null
O/A cycle
transceiver.sender.replaceTrack(track2); // Do we know if track2 is compatible?

// 3. And this?
transceiver = pc.addTransceiver();
transceiver.sender.replaceTrack(track2);
O/A cycle
```
I would assume 3) to work the same as 1), but from my understanding of replaceTrack() it would fail without an initial O/A cycle, so 3) would require an additional O/A cycle between addTrack() and replaceTrack(). But if a track is needed to negotiate codec settings, that wouldn't work either, and you would have to always use addTrack().

-- 
GitHub Notification of comment by henbos
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1662#issuecomment-354423587 using your GitHub account

Received on Friday, 29 December 2017 09:47:50 UTC