Currently getExtendedRtpCapabilities in mediasoup-client iterates through codecs in the order they are on the server.
This may be desirable in some cases and not in others, like when browser prefers H264 because it has hardware acceleration for it.
Would be nice to have an option to prefer codecs order from the browser instead. Thoughts?
I can make a PR with this change if it is something that looks useful to others.
The app can call transport.produce() with the desired codec:
Yes, but you need to know what desired codec is. Currently it is the first codec in server’s capabilities list that browser supports, but what I’m interested in is the first codec in browser’s capabilities list that server supports.
So if server returns:
VP8
RTX
VP9
RTX
H264
RTX
And browser:
H264
RTX
VP8
RTX
Current result is VP8, while I’d expect H264, at least as an option.
So currently to achieve this one has to copy-paste a bunch of code from mediasoup-client or manually create and parse SDP to see what browser supports and prefers.
Is this really a so important feature to have? I’ve never needed this. Typically you don’t want to let the client choose the codec but, instead, decide it via application logic. This is not just about encoder capabilities but also about decoders (receivers).
In my case I want to follow browser decision. If browser prefers H264, it often indicates hardware acceleration, like on iOS, which makes a huge difference for user experience on low-power devices. But I don’t want to force H264 either if browser likes VP8 more.
Ability to get native RTP capabilities (possibly filtered according to router capabilities) out of device instance to make this decision on application level would be sufficient as well. I just want to avoid adding separate SDP parser to the app if possible.
I’d accept a PR that adds a localOrder: number in each codec capability in mediasoup-client, pointing to the order of such a codec in the client capabilities, so the app can layer choose it based on that field and use the codec field in ProducerOptions. Good?
That could work, but it doesn’t fit well into the RtpCodecCapability type
We can modify the type 
I ended up doing the ugly thing: accessing device._handlerFactory to get my hands on getNativeRtpCapabilities().
I really don’t like adding properties to RtpCodecCapability just for this, it makes data structure awkward.
I don’t really see how adding a nativeOrder in RtpCodecCapability is that ugly.
It has nothing to do with with RTP or codec or capability, it is a higher level concept of ordering between codecs. And corresponding data structure on backend will not have localOrder property. So for nicer API it must be somewhere else. It would work that way of course, it is just awkward to me.
Yes, agreed. However this is complex. Having a separate “locally ordered” array of codecs is not that easy. For example, RTX codecs must be placed after their corresponding video codecs.