Encoding complexity

[sprangerik]

This introduces a new enum RTCEncodingComplexity and adds an encodingComplexity member to RTCRtpEncodingParameters to allow applications to hint at the desired trade-off between quality and CPU/power consumption for an encoding.

Fixes #191

---

Preview | Diff

[youennf]

Given this might be even more useful to WebCodecs encoders, it seems we should discuss this in WebCodecs repo and maybe piggy back on what is added there in terms of enum for instance.

[youennf]

@sprangerik, do you plan to file an issue to WebCodecs?

[sprangerik]

@sprangerik, do you plan to file an issue to WebCodecs?

I do plan to file an issue with WebCodecs - but I think that implementation will look quite different. This enum is a high-level hint to UA and then it does its best.

WebCodecs is a low-level API in comparison, and there this type of hint doesn't make much sense. Instead, we'll need a way to figure out what the capabilities of the encoder are (i.e. the range of valid speed settings) so that a user can know that changing the value will actually change the behavior. I also think that parameter should be done on a per-frame bases in WebCodecs, which makes no sense for WebRTC.

[jan-ivar]

I'd expect a higher-level API to need less granularity not more.

[sprangerik]

WebRTC (the higher-level) API would indeed have less granularity - as in these ~5 or so enum "hint" values.

(I've been swamped by other things, but will upload a change to reduce the number of values soon, as discussed.)

WebCodecs on the other hand should have a strict mapping to underlying implementation - so e.g. libvpx VP8 would expose the full 1..12 range. OpenH265 would have 1..3. That means we also need a way query what settings are available for the encoder instance in question.