degradationPreference is under-specified

[aboba]

degradationPreference appears to have been implemented differently between browsers, but the
differences are not being picked up in the WPT test, which only tests getting and setting values.

Currently Section 5.2.2 says:
"When bandwidth is constrained and the RTCRtpSender needs to choose between degrading resolution or degrading framerate, degradationPreference indicates which is preferred."

In the current Edge implementation, degradationPreference is interpreted as providing a content-hint to the encoder, allowing it to differentiate between applications desiring a bias toward "detail" (a degradationPreference of "maintain-resolution" or "motion" (a degradation-preference of "maintain-framerate").

However my understanding is that other browsers don't implement degradationPreference this way.

[Orphis]

As for Chrome, it's not exposed right now since we are still tuning the balanced degradation preference which is supposed to be the default. We also default internally to "maintain framerate", so we'd be changing the current default behavior in lots of apps, which is tricky to handle.

I don't think we've had any issues interpreting the behavior of the flag though. "Maintain framerate" will try to adapt the frame size to keep the transmission smooth, "maintain resolution" will not change the frame size but drop frames as needed.

[aboba]

@Orphis Is it accurate to say that in the Chrome implementation degradationPreference is orthogonal to content-hints? That is, there is no interaction between a degradation-preference of "maintain-framerate" and a content-hint of "detail" (or between a degradation-preference of "maintain-resolution" and a content-hint of "motion")?

[Orphis]

@aboba I believe that is correct.

[aboba]

Some of the concerns described here may also apply to degradationPreference.

[henbos]

When degradationPreference is moved to webrtc-extensions, this issue can move there as well.