Consensus call: MaxFramerate for RTCRtpEncodingParameters

At the Sapporo meeting, we had quite a bit of discussion on how to
specify framerate restrictions for encodings in a simulcast.

One suggestion was to follow the model of "scaleResolutionDownBy" and
specify a divisor that an encoding would use compared to the "main"
encoding. The argument against this was that if the "main" encoding
dropped its framerate for any reason, the effect on the other encodings
was likely to be different from what the app wanted - if the "main" was
60 fps and the "backup" was 1/4 of that (15 fps), and for some reason
(low light?) the "main" dropped to 15 fps, the "backup" would drop to
3.75 fps.

The other suggestion was to specify the max framerate as a
"maxFramerate" parameter - which, in the same situation, could lead to
multiple encodings with the same framerate (in the same configuration as
above, both would send at 15 fps); my impression from the meeting was
that there was not a strong consensus one way or the other; some
speakers clearly preferred the "maxFramerate" solution, and it wasn't
clear that anyone strongly preferred the "scaleFramerateDownBy" solution.

It was, however, clear that people wanted the ability to have encodings
with different framerates, so the spec needs to say *something*; based
on my perception of the discussion as described above, my impression is
that it's more reasonable to specify "maxFramerate" than to specify
"scaleFramerateDownBy".

This is a consensus call for adding a maxFramerate parameter to the
dictionary "RTCRtpEncodingParameters" in the spec. If you have a
preference for or against this addition, please speak up now.

This consensus call runs until Friday, December 18. The chairs will
judge consensus based on comments received at that time.

Harald, for the chairs

[Note: The working editors' draft (not the published editors' draft) of
the spec already contains this addition. If consensus is against adding
it, we'll roll this change back before publishing another editors' draft.]

Received on Monday, 14 December 2015 10:48:38 UTC