W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2014

RE: Proposed Change to RTCRtpSender "doohickey" proposal

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>
Message-ID: <6a582af9f4a04a5d883cdcc350d53bba@SN2PR03MB031.namprd03.prod.outlook.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:55 UTC