- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 15 Sep 2015 15:18:15 -0700
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: Jan-Ivar Bruaroey <jib@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 15 September 2015 at 15:00, Harald Alvestrand <harald@alvestrand.no> wrote: > Martin, can you clarify what you were asking? I'll try to make this as precise as possible: Premise 1: The resolution of a MediaStreamTrack is not constrained by RTCPeerConnection. Premise 2: RTCPeerConnection can negotiate a session that places limits on the resolution of video that it can transmit. Conclusion: MediaStreamTrack might produce a resolution that RTCPeerConnection cannot convey. Yes, the point is that the source might change. The common case - where MediaStreamTrack is not constrained in any way - would easily allow this to happen. > I did not understand Martin to ask about what happens when the negotiation > window on a PeerConnection that is a sink to a MediaStreamTrack changes - > that's a completely different problem, and I agree that the spec is silent > on what should happen then. Yes, I did not ask that question because I believe it to be a non-issue. Negotiation is informed by the state of the MediaStreamTrack. RTCPeerConnection should not renegotiate something that the MediaStreamTrack is incapable of producing.
Received on Tuesday, 15 September 2015 22:18:43 UTC