receiver.hardwareAcceleration attribute instead of disableHardwareDecoding() static method

[jan-ivar]

It doesn't look like RTCRtpReceiver.disableHardwareDecoding() has shipped anywhere.

Mozilla feedback in https://github.com/mozilla/standards-positions/issues/728 was originally negative (though a formal position never formed).

But after recent review, we'd like to propose a slightly different API shape that Mozilla would get behind:

partial interface RTCRtpReceiver {
  HardwareAcceleration hardwareAcceleration = "no-preference";  
}

It's a receiver attribute instead of a static method.

Importantly for us, HardwareAcceleration is defined in WebCodecs, which has a page-long note about when the UA might override webpage preference.

We think this would resolve our concerns raised in the issue, specifically around the UAs ability to override website preference in situations like after a hardware codec fix.

[aboba]

Related: #98

TPAC 2022 slides

[henbos]

This is much better, a global static method had some obvious limitations, but being able to control a preference on a receiver does make sense.

[fippo]

Let me give you a brief recap since it has been a while:

• the API was intentionally designed to be cumbersome. As also noted in the mozilla position letting JS decide is not a great idea. But as the list-of-doom of hardware-acceleration related issues showed (and it has grown since) it is a practical problem.
• The API was for both senders and receivers (or encoders and decoders respectively). Encoders are typically the source of the issues like undershooting
• there was enough consensus to merge the PR, yet the "Mozilla position" (a conglomerate!) went the other way?
• 2+ years later the suggestion is to go back to the drawing board?

@jan-ivar, three questions:

• how do you plan to address the (theoretical) fingerprinting concerns, e.g. by comparing decode times with and without hardware on different receivers (or senders)
• Does Firefox have hardware encoder and decoder support? This is somewhat hard to determine since Firefox still lacks both decoderImplementation as well as powerEfficientDecoder stats but the result of disabling the OpenH264 plugin suggests "no".
• What concrete issue do you have with decoders? Most of the time the issues are related to rate control and undershooting but that is on the encoder side