Simulcast behavior #1996
Simulcast behavior #1996
Conversation
Work-in-progress, do not merge. Fix for Issue #1964
|
@fippo Any thoughts? |
webrtc.html
Outdated
| can be utilized to set the maximum bitrate of a simulcast stream. However, | ||
| <code>maxBitrate</code> does not influence the user agent's response to congestion, | ||
| including allocation of bandwidth between simulcast streams or the decision to | ||
| stop sending one or more streams.</p> |
There was a problem hiding this comment.
Does it make sense to have a maxBitrate per-layer and not per-sender? Does the application want/need this amount of control?
There was a problem hiding this comment.
Having maxBitrate per-layer is useful in scenarios where the application wants to control rates of streams (e.g. to make sure a thumbnail doesn't use too much bandwidth).
There was a problem hiding this comment.
this is also what firefox supports today also.
webrtc.html
Outdated
| <section id="maxbitrateinsimulcast"> | ||
| <h3>maxBitrate</h3> | ||
| <p><code><a>RTCRtpEncodingParameters</a></code> dictionary member <code>maxBitrate</code> | ||
| can be utilized to set the maximum bitrate of a simulcast stream. However, |
There was a problem hiding this comment.
Bitrate can be measured for any interval of time, and packets are likely measured discretely, so depending on how you measure things a UA may or may not at times exceed the bitrate (e.g. if you measure the last second, you have a "budget" of up to 1 second to work with, but could also work with 10 seconds or 10 ms). Should this say "target maximum bitrate" (or bikeshed: clarify how bitrate is measured)? Same comment for framerate.
There was a problem hiding this comment.
The TIAS definition is referenced in the maxBitrate member definition.
| between simulcast streams sent by an <code><a>RTCRtpSender</a></code> object.</p> | ||
| </section> | ||
| <section id="maxbitrateinsimulcast"> | ||
| <h3>maxBitrate</h3> |
There was a problem hiding this comment.
What if unreasonably low bitrates are used? What if 0 is used? Same comment for framerate.
I assume there is some softness to these restrictions, where the UA only has to "try" to obey?
webrtc.html
Outdated
| <h3>maxFramerate</h3> | ||
| <p><code><a>RTCRtpEncodingParameters</a></code> dictionary member <code>maxFramerate</code> | ||
| can be utilized to set the maximum framerate of a simulcast stream. However, | ||
| <code>maxFramerate</code> does not influence the user agent's response to congestion, |
There was a problem hiding this comment.
Here and above: This only sets a "max", not a "min"; would response to congestion control ever lead to an increase of bits/frames?
There was a problem hiding this comment.
When congestion control says "plenty of bandwidth available", it will lead to an increase in bitrate, but shouldn't go over maxBitrate anyway.
There was a problem hiding this comment.
the use-case for this is to support things like "give me the low-resolution layer only at 10fps, I am only going to show thumbnails anyway", right? 👍
| <code>maxFramerate</code> does not influence the user agent's response to congestion, | ||
| including allocation of bandwidth between simulcast streams or the decision to | ||
| stop sending one or more streams.</p> | ||
| </section> |
There was a problem hiding this comment.
May setting different settings on different layers in any way affect the encoder's/decoder's performance? Are there inabilities to adhere to the limits?
If an encoder is not able to produce different framerates on different layers, should it take the lowest, highest or average framerate based on layers?
Should there be guidance about what reasonable values are? Should the UA be allowed to ignore application hints?
|
one thing I noticed while discussing https://bugzilla.mozilla.org/show_bug.cgi?id=1474661 with folks (:wave: @docfaraday) that there is no way to set a target bitrate per layer. So I may (today) request max bitrates of 500, 800 and 2300 and would only get... 150, 500 and 2300 or something like that which is hardcoded deep down in webrtc.org |
|
@aboba will make updates according to comments. |
webrtc.html
Outdated
| <code>maxFramerate</code> does not influence the user agent's response to congestion, | ||
| including allocation of bandwidth between simulcast streams or the decision to | ||
| stop sending one or more streams.</p> | ||
| the user agent is not required to take <code>maxFramerate</code> into account when |
There was a problem hiding this comment.
Suggested text: "The user agent is free to allocate bandwidth between the encodings, as long as the maxFramerate is not exceeded". And similar above.
webrtc.html
Outdated
| responding to congestion, such as modifying the allocation of bandwidth between | ||
| simulcast streams or deciding when to stop sending one or more streams.</p> | ||
| can be utilized to set the maximum bitrate of a simulcast stream. However, the user | ||
| agent may not take <code>maxBitrate</code> into account in responding to congestion, |
There was a problem hiding this comment.
Still think "may not" is a bad echo of the RFC 2119 MAY NOT (equivalent of MAY); suggest "may choose to not" to break it up.
|
PTAL @henbos |
|
Should be ready to review. |
Partial fix for Issue #1964
Preview | Diff