Introducing a codec specific 'quantizer' mode for VideoEncoder

[Djuffin]

A codec specific quantizer is set for each video frame for constant quality or fine tuned external rate control.

Addressing Issue 270

---

Preview | Diff

[aboba]

So quantizer support is only for VP9?

[Djuffin]

So quantizer support is only for VP9?

No, this PR is deliberately limited to VP9 to demonstrate the idea and keep the change small.
AV1 and H264 will follow.

[solmaks]

If there is no technical reason to exclude other codecs, can we come up with codec agnostic API surface from the get go?

[aboba]

Could we have "VideoEncoderEncodeOptions" instead of "VideoEncoderEncodeOptionsForVp9"?

Also, might be helpful to expose the QPmin and QPmax and to use [EnforceRange] so quantizer values can't be set outside the range.

[Djuffin]

If there is no technical reason to exclude other codecs, can we come up with codec agnostic API surface from the get go?

Could we have "VideoEncoderEncodeOptions" instead of "VideoEncoderEncodeOptionsForVp9"?

We can certainly simply put quantizer into VideoEncoderEncodeOptions, like it was originally proposed in #270, but there is a concern that QP is too codec specific in its range and effect on encoding. It's like having very different parameters assigned to the same name.

Also, might be helpful to expose the QPmin and QPmax and to use [EnforceRange] so quantizer values can't be set outside the range.

I though [EnforceRange] only enforces integer range.
QPmin and QPmax are part of codec spec, power users that use per-frame QP probably know it already, don't they?

[Djuffin]

@padenot @youennf
What do you think about quantizer being codec specific rather than a generic parameter?

[solmaks]

Introducing an API surface that will need changes/updates for every new video codec is an unnecessary complexity (and extra work for everyone). For instance, getting this available for H264 will required a spec iteration (and more code in implementation), same for AV1, same for H265, same for some new codec 10 year later down the road. Is there a concern that QP does not apply to or does not have a similar effect (higher QP means higher compression, lower QP means lower compression) on current generation of video codecs used in the industry?

[Djuffin]

I don't feel very strongly about it, but since QP has different ranges for different codecs it seems logical to put them into codec specific parts of the spec.

[aboba]

It is probably beyond the scope of this PR, but I'd note that the potential addition of segmentation metadata (for face detection and/or background blur) to the VideoFrame has raised the question of per-macroblock QP, which would allow the encoder to focus its efforts on "important" macro blocks (e.g. the macroblocks corresponding to the foreground, rather than a (blurred) background).

[Djuffin]

This PR was approved at the last meeting of the media working group.