[RTCRtpReceiver Decoder Fallback] API shape feedback

[fippo]

• What is codecString if there is no (SW) fallback? If it is optional does the IDL need to be changed?*

• codecString is not really defined. It isn't mimeType and we need more than the mime type (e.g. video/H264) to determine the actual codec and decoder. We should probably go for mimeType and sdpFmtpLine as defined in codec stats, maybe add payloadType too while we are at it (but see the lastpoint). Note these will not change when falling back

• Add decoderImplementation under the same exposure criteria as in stats (read: @Diego-Perez-Botero still won't get it)

• rename powerEfficient to powerEfficientDecoder as in stats? (I like my bikeshed in Faluröd)

• Mention that this invalidates the stats cache (see here)

Thoughts @nishitha-burman @SteveBeckerMSFT?

[henbos]

In getParameters() codecs are exposed as RTCRtpCodecParameters, which has payloadType, mimeType, sdpFmtpLine, etc.

So you could have

interface RTCDecodeErrorEvent : Event {
  readonly attribute RTCRtpCodecParameters codec;
};

Or you can make the parameter optional with ?, but even if we didn't have a codec implementation to fall back to, it would still be true that the error happened for this codec, so I don't know if you want to add an error enum or recovery enum that indicates we went from HW to SW or if we permanently failed