- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Wed, 30 Apr 2014 22:29:05 +0000
- To: Martin Thomson <martin.thomson@gmail.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>
- CC: Justin Uberti <juberti@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Martin said wisely: For instance, you could say to the browser: layeringTypesAllowed: ["temporal", "spatial", "quality"] (or some subset thereof) and gain some advantage. You could say to the browser maxLayerDepth: 2 and gain some advantage. You could say maxAdditionalLayers: 3 and gain some advantage. [BA] The above Capabilities might be all that would be needed as input for the browser to provide a suitable RTCRtpEncodingParameters object that the developer shouldn't need to muck with. Direct manipulation should be discouraged -- if this is allowed we will end up replicating many of the same issues we've had with SDP manipulation between createOffer and setLocalDescription. [Cullen] We need to add RTCRtpEncodingParameters to the Receiver object. [BA] Be careful. It's called RTCRtpEncodingParameters for a reason -- the object relates to encoding, not decoding. Many of the attributes of the object could make little or no sense for a decoder -- and trying to manipulate them could be dangerous. For example, what does maxBitRate mean for a decoder??
Received on Wednesday, 30 April 2014 22:29:46 UTC