- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Wed, 24 Jan 2018 23:25:59 +0100
- To: Justin Uberti <juberti@google.com>
- Cc: Peter Thatcher <pthatcher@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 24 January 2018 at 22:57, Justin Uberti <juberti@google.com> wrote: >> 2) Make it better. Specially, allow more granular control on how >> RTCRtpParameters are dynamically given to the RTCRtpSender (so instead >> of passing a full JSON "blob" that must be fully re-inspected each >> time, let's just modify a specific subset of fields in those >> parameters). > > > Thanks. If you look at Peter's proposal, he's suggesting something that's > pretty close to that. Basically, instead of a RtpSender, you could get > direct access to an encoder object itself, and would have full control over > its configuration. True. > I think this would actually be a *lower* level API than ORTC. Sure. Just wondering about how to signal those RTP parameters modification to the remote peer. In some cases that's needed. In others it's not. Something like this comes to my mind: rtpSender.changeSomething( { foo: 100000 }) .then((changes) => { if (changes) mySignaling.send(changes); }) .catch((error) => { console.error("could not apply new settings"); }); -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Wednesday, 24 January 2018 22:26:43 UTC