InvalidModificationError: Failed to execute 'setCodecPreferences' on 'RTCRtpTransceiver': Invalid codec preferences: Missing codec from send codec capabilities.
So we had to add the following workaround to append RTCRtpSender.getCapabilities('video') output before calling setCodecPreferences(...):
// Even though our transceiver is 'recvonly', LibWebRTC demands that it always has something
// to offer regardless of transceiver.direction. Thus, we must not forget to add the RTCRtpSender's
// codecs to the very end. Some devices don't support H264 for *outgoing* video and will hit
// InvalidModificationError during the setCodecPreferences(...) call if we don't do this.
//
// See VerifyCodecPreferences at
https://chromium.googlesource.com/external/webrtc/+/master/pc/rtp_transceiver.cc const supportedSenderVideoCodecCapabilities = RTCRtpSender.getCapabilities('video')?.codecs ?? [];
codecPreferences.push(...supportedSenderVideoCodecCapabilities);
videoTransceiver.setCodecPreferences(codecPreferences);
From my reading of this PSA, it sounds like the ugly workaround is now going to blow up in our face. However, my reading of the M124 change indicates that the original Android problem that we were hitting is also going away with M124+, since the VerifyCodecPreferences implementation doesn't care about the sender codecs anymore. Could you please confirm that my understanding is accurate? :)