w3c
Deprecate audio/video enumeration in getCapabilities in favour of Media Capabilities API
Given Media Capabilities is better suited to identify the supported audio video codecs, and given getCapabilities as a synchronous API is not very well suited, we might want to remove some of the functionality of getCapabilities.
Currently, Media Capabilities does not surface "fake" codecs (e.g. telephone-event, CN, FEC, RTX, RED), only "real" ones (e.g. Opus, G.711, VP8, H.264, etc.). Unless this were to change, Media Capabilities API cannot reach parity with getCapabilities() on that dimension (though MC provides more information in other respects). It comes down to whether Media Capabilities API has a goal of superceding getCapabilities() API or not.
getCapabilities() output can also be used with setCodecPreferences(). Replacing a single API call with a complicated series of calls to MediaCapabilities seems like a usability regression.
Conclusion from the April 26 interim meeting is that mediaCapabilities should focus on "real" codecs, and not incorporate information on "fake" codecs (e.g. telephone-event, CN, FEC, RTX, RED). As a result, mediaCapabilities() cannot provide all the information provided by getCapabilities(). Therefore getCapabilities() cannot be deprecated.
It is beneficial to remove the information that is redundant with media capabilities, meaning removing "real" codecs if we can find a reasonable definition for these. This could for instance mean deprecating getCapabilities and introducing an API dedicated to these fake codecs.
Or deprecating the codecs dictionary field and introducing another dictionary for rtx and friends.
I would not be in favor of deprecating getCapabilities for real codecs for the reasons explained by @Orphis
https://github.com/w3c/webrtc-extensions/issues/95#issuecomment-1109508795
