[IMP] add simulcast

[ThanhDodeurOdoo]

This commit adds the support for simulcast:

Simulcast is a way to let producers sent multiple version of the streams
as different layers of quality. This allows the server to select
the optimal layer based on the available bandwidth for each client.

Two env variables are used to control this feature:

VIDEO_MAX_BITRATE: Specifies the bitrate for the highest encoding
layer per stream. It sets the maxBitrate property of the
highest encoding of the RTCRtpEncodingParameters and is used
to compute the bitrate attributed to the other layers.

MAX_BITRATE_OUT: The maximum outgoing bitrate (=from the server) per
session (meaning that this cap is shared between all the incoming
streams for any given user). The appropriate simulcast layers used by
each consumer will be selected to honor this limit. If the bitrate is
still too high, packets will be dropped. Without this limit, the
connections will use as much bandwidth as possible, which means that
the simulcast layer will be chosen based on the client (or server) max
available bandwidth.

This commits also bumps the minor version as the bundle and the server
need to be updated to benefit from the feature (although both the
client and the server are backwards compatible).

[ThanhDodeurOdoo]

I tested a bit, bitrate limits appear to be respected

more tests could be made in the PR that updates the sfu bundle in the odoo codebase

[alexkuhn]

Maybe I'm wrong, but a scale down of 4 implies a reduction of bitrate by 16, not 4, because it's a fourth of x and a fourth of y, resulting to 16 less pixels to render for an equivalent framerate, thus roughtly a bitrate divided by 16.

Of course, this math works with the bitrate scaling with pixels, which is not necessarily entirely true with the compression algorithms at hand. Probably the scale down has diminishing return of reduced bitrate if you take the compression algorithm into account, but probably not to the point it's close to linear with 1080p for example.

[ThanhDodeurOdoo]

Yes the resolution should scale down by the square of the value, but as you mentioned it may not scale exactly like that and there is likely some constant overhead on top of it, if we are too strict we may lose packets at the lower resolutions. Since it's a cap it shouldn't be a problem to have a generous margin since the lower resolutions will only use the bitrate they need.

[ThanhDodeurOdoo]

@seb-odoo

[seb-odoo]

No objection from me if it works and others already approved.

Some nitpicks in comments.

[seb-odoo]

Possible to add tests for simulcast in the future?

[ThanhDodeurOdoo]

@seb-odoo It is difficult to test because it would require a stream mock that takes bandwidth and actual video resolution into account.
Note that with these parameters we are almost directly at the webRTC API layer ( https://w3c.github.io/webrtc-pc/#rtcrtpencodingparameters ).