- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Jun 2018 07:27:47 +0000
- To: public-webrtc-logs@w3.org
alvestrand has just created a new issue for https://github.com/w3c/webrtc-pc: == Order of RTCRtpSendParameters.encodings is not described == In the RTCRTPSendParameters.encodings, the description is: "A sequence containing parameters for RTP encodings of media" In "getParameters", it says "encodings is populated based on the RIDs present in the current remote description." Example 15 says: pc.addTransceiver(stream.getVideoTracks()[0], { direction: 'sendonly', sendEncodings: [ {rid: 'f'}, {rid: 'h', scaleResolutionDownBy: 2.0}, {rid: 'q', scaleResolutionDownBy: 4.0} ] This seems to indicate that the spec-writers were thinking in terms of "highest resolution first, lowest resolution last". But this is never written down as a rule anywhere. Neither is the idea that order stays consistent between calls. The issue came up because one lower level implementation had a built-in assumption that lowest resolution would go first and highest resolution would go last - the opposite of this example. Possible resoutions: a - Declare that order is not fixed; the implementation can reorder encodings whenever it wants b - Declare that order is fixed, but resolutions can occur in any order c - Declare that order is fixed, and that scaleResolutionDownBy has to be greater or equal to previous encoding (ascending scaleResolutionDownBy) (or the other way round) a would seem to be the alternative that requires minimal changes to implementations. tagging @henbos @orphis @deadbeef Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1896 using your GitHub account
Received on Friday, 15 June 2018 07:27:51 UTC