I have a strange issue I wonder if anyone has come across. On my web client when accessed using android and chrome, the initial call to device.load() provides only the opus audio codec in the device.rtpcapabilities. However after a refresh of the page, I get a full codec list in the device.rtpcapabilities. Because of this I can’t do any video until the page is refreshed, which is not an ideal solution, but the only one I can find that works.
if codec count < 2 then window.location.reload();
Since I can’t call device.load() a second time, I don’t know any other way to resolve it. I have tried to delay the call until the user presses a button on the page, but this did not resolve the issue.
I realize this is probably a chrome issue, but wondering if anyone else has seen this or there is a known workaround that anyone has come up with.
Have you solved the issue? I have the same one with Firefox and it’s pretty strange. I get router rtp capabilities with 2 video codecs, then send it to device.load({routerRtpCapabilities})
and then try to get device.rtpCapabilities, but actually receive headerExtensions with codecs array empty
Well, that may happen if the given codecs in routerRtpCapabilities are not supported by Firefox, right? I mean: that’s exactly what mediasoup-client does, verify which codecs are supported and build a proper local rtpCapabilities.
Then you just complain because codecs array is empty. Well, yes it may be based on given input, but we don’t know the input. Try passing vp8 codec and it will work.
Yes, I know, you want H264. Then set a H264 profile supported by Firefox into router codecs.
He said android chrome, right? Well, maybe a big in Android chrome. Just try by creating a PeerConnection with receive audio/video and see how the SDP offer looks like. That’s what mediasoup-client does in order to retrieve capabilities.
Yes, my issue is with android and chrome. I have not tried firefox. I will. Good to know I am not the only one though. I will look into the idea of creating a peerconnection directly and see if that gives different result.
My solution at the moment is to detect when this occurs, set a cookie and do a page refresh. If it happens again (by checking cookie) I give up. But it always seems to get it the second time.
Agreed, more of a ‘workaround’ than a proper solution. I am going to verify the issue still exists in the latest dev branch. If it does I will report it. Thanks for all the help.
This problem occurs typically with Android WebViews, which are based on Chromium and not Chrome.
Chromium, contrary to Chrome, is built without the proprietary codecs enabled, notably without H264 (see rtc_use_h264 flag).
However on Android the “MediaCodec” and “OMX” libs are able to support H264 software decoding, as long as it’s a baseline profile => using profile-level-id: '42e01f' is the safest bet.
I’ve noticed that due to this external lib kicking-in, there is an async problem that explains why it does not work the first time.
I’ve also seen cases where RTCPeerConnection + mediasoup device loading is not enough.
The strategy I ended up using is:
Create and load mediasoup Device
If msDevice.rtpCapabilities.codecs.find() does not find the codec, create the fake RTCPeerConnection. Otherwise we’re good.
Create and load another mediasoup Device from scratch.
Please note for the fake RTCPeerConnection that you can strip most of the config options, writing simply:
