Re: What would you like to see in WebRTC next? A low-level API?

On Wed, Jan 24, 2018 at 2:25 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 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");
>   });
>
>
In this model, I think the app (who may very well control the actual
packetization) has the full responsibility for determining what important
changes have occurred and notifying the remote peer of such changes. The
interface to the encoder is likely to be more along the lines of Android's
MediaCodec
<https://developer.android.com/reference/android/media/MediaCodec.html>, or
iOS' VideoToolbox <https://developer.apple.com/documentation/videotoolbox>,
where the output is a bitstream as opposed to a set of RTP packets.