degradationPreference is under-specified

[aboba]

Moved from w3c/webrtc-pc#2248

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]

Do you believe that the recent changes merged into the specification have fixed the issue or is there more work to do?

[jan-ivar]

@Orphis

On desired behavior: I guess it depends on whether we want it to do more. As I understand, the present text was moved from WebRTC-pc and it does not spell out Edge's behavior, which I interpret to mean Edge's behavior is non-compliant.

If we want to include Edge's behavior, then more work is needed. At the same time, I don't see implementing what is there now as an obstacle to adding that later (unless we want ONLY Edge's behavior). @aboba?

On testing: I remain concerned the current behavior is not easily testable #29. But perhaps implementations may reveal ways of doing that?

[alvestrand]

Given that the purpose of the specification is to provide hints, and it is in the nature of a hint that the UA may choose to disregard it, it seems hard to test that the behavior is non-conformant (as opposed to "just not very effective").

For testing degradation-preference: If we had bandwidth limiting, we could write tests that a) send a synthetic video stream and measures its bandwidth, b) reduce its bandwidth below , and c) analyze the result as "more blur", "fewer frames", or "lower resolution". The two last ones are probably easy to test, while "blurrier" is more fuzzy.

Would RTCRtpEncodingParameters.maxBitrate have the desired impact?

[fippo]

See also https://bugs.chromium.org/p/webrtc/issues/detail?id=15484 where I would have expected contentHint and degradationPreference to behave the same but they differ ;-)