- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Jan 2018 19:42:59 +0000
- To: public-webrtc-logs@w3.org
> Do we need negotiation to go from "there was never a track" to "there is a track"? In some cases. The example of when "negotiation is needed" is "a video track differing in raw vs. pre-encoded format." So, going from "there was never a track" to "there's a pre-encoded track" would require negotiation, since it would need to negotiate the pre-encoded format. If I understand correctly. > 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? My assumption is that, ignoring this "pre-encoded" case, the O/A will look the same. That's how Chrome currently works. > If we want it to be able to fail in case renegotation is needed because we don't want black frames until the O/A cycle has completed (in the case of already sending another track), then another operation is needed to say "I want to be able to send this track" such that when that operation completes, including the O/A, you can do replaceTrack() again. That seems pretty complicated... I wonder if this is actually going to be an issue in practice or not. I'm still fuzzy on what things will require renegotiation. > A brief chat with @alvestrand cleared up some my confusion, that the intent is to use setParameters() to decide codec params and set direction and renegotiate as to then allow using replaceTrack() without it being rejected. I thought `setParameters` was just for tweaking the knobs of how a track is sent, within the bounds negotiated by the O/A. How exactly does it interact with `replaceTrack`? -- GitHub Notification of comment by taylor-b Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1662#issuecomment-354857508 using your GitHub account
Received on Tuesday, 2 January 2018 19:43:06 UTC