>This seems like a pretty big hammer to solve a fairly small problem. This proposal adds 6 new API points for the purpose of >changing the order of codecs in createOffer, which seems like a high cost-benefit ratio. And while the use cases listed here are >helpful, they seem somewhat contrived to me, since it seems unlikely that the application can make better choices about >bandwidth >or power consumption than the browser. [Raju] Per my understanding, the main object of this draft can be achieved with no additional APIs and with just the proposed introduction of preferredAudioCodecs and preferredVideoCodecs options to RTCOfferAnswerOptions constraint of createOffer()/createAnswer(). So, IMO I don't think getCodecPreferences()/setCodecPreferences() add much value, so can be delayed or dropped. The need for getSupportedAudioCodecs()/getSupportedVideoCodecs() in 1.0 can be questionable as the application can specify codecs order per known codecs (or get the list via a dummy createOffer() call). The draft talks about fulfilling A5 in [I-D.ietf-rtcweb-use-cases-and-requirements], but I do not see any explicit mention of how codecs can be removed? preferredAudio/VideoCodecs constraint only specifies the order of preference. Don't you need another constraint to exclude specified codecs? It's probably a bad design to have codecs not in the preferred list be removed automatically. BR Raju
Received on Monday, 21 July 2014 18:57:02 UTC