Video codecs negotiation

Hi all, we’ve got a self-hosting instance of Jitsi and sometimes one or more clients have back box displayed instead of video feeds. I suspect that’s due to different video codecs being used. Could you please provide some hints at how one can trace video codecs negotiation process (if that’s possible at all)? What logs to enable and what entries to search for in there? Thanks!

Maybe your Jitsi has no support for unified plan if it’s an old version

@emrah : It’s a dockerized version stable-6726-1. Do you know if that’s possible to trace video codecs negotiation process by logs or browser console or somehow else?

Did you check chrome://webrtc-internals/ in Chrome

Thanks @emrah , I’ll look at that.
Is there a way to troubleshoot cases when there are only mobile devices in a conference? Is there anything logged on Jitsi side?

Hi @jallamsetty
here’s a post for the question I raised on today’s call. I’ll post my findings with a newer version here.
Meantime, I’d like to say that we’re unable to reproduce the issue on meet.jit.si, so it should be something on our side. That’s actually why I was asking about ways to troubleshot it.
Thanks!

Yes, I haven’t been able to reproduce it on meet.jit.si. Are you seeing this no video issue on both iOS and Android ? Please note that whenever mobile Safari is involved, there won’t be p2p connection even if there are only 2 users in the call since cross browser p2p has been disabled. What makes you suspect its a codec negotiation issue ? There are a few known browser bug on Safari which would cause this if the sender is running in plan-b.

You can filter the browser console logs on the sender side using the string “codec”. The application does log the codec preferences and the codec switching operations. For example, the below logs are from a call where a Safari user joined prompting a VP9->VP8 switch and leaving makes the VP8->VP9 switch happen.

2022-03-07T17:25:57.817Z [modules/RTC/CodecSelection.js] <new So>:  Codec preferences for the conference are JVB: vp9,
            P2P: vp9
Logger.js:154 2022-03-07T17:25:58.299Z [modules/RTC/TraceablePeerConnection.js] <new Ba>:  Using RTCRtpTransceiver#setCodecPreferences for codec selection
Logger.js:154 2022-03-07T17:25:58.309Z [modules/RTC/TraceablePeerConnection.js] <new Ba>:  Using RTCRtpTransceiver#setCodecPreferences for codec selection
Logger.js:154 2022-03-07T17:25:58.545Z [modules/xmpp/JingleSessionPC.js] <Qr.setVideoCodecs>:  JingleSessionPC[session=JVB,initiator=false,sid=7pmf7t58qqr3f] Switching video codec from vp8 to vp9
Logger.js:154 2022-03-07T17:25:58.545Z [modules/xmpp/JingleSessionPC.js] <Qr.setVideoCodecs>:  JingleSessionPC[session=JVB,initiator=false,sid=7pmf7t58qqr3f] Queued setVideoCodecs task
Logger.js:154 2022-03-07T17:25:58.548Z [modules/xmpp/JingleSessionPC.js] <Qr.setVideoCodecs>:  JingleSessionPC[session=P2P,initiator=false,sid=1fddd9d71980] Switching video codec from vp8 to vp9
Logger.js:154 2022-03-07T17:25:58.548Z [modules/xmpp/JingleSessionPC.js] <Qr.setVideoCodecs>:  JingleSessionPC[session=P2P,initiator=false,sid=1fddd9d71980] Queued setVideoCodecs task
Logger.js:154 2022-03-07T17:25:58.687Z [modules/xmpp/JingleSessionPC.js] JingleSessionPC[session=P2P,initiator=false,sid=1fddd9d71980] setVideoCodecs task is done
Logger.js:154 2022-03-07T17:25:58.738Z [modules/xmpp/JingleSessionPC.js] JingleSessionPC[session=JVB,initiator=false,sid=7pmf7t58qqr3f] setVideoCodecs task is done
Logger.js:154 2022-03-07T17:26:23.321Z [modules/xmpp/JingleSessionPC.js] <Qr.setVideoCodecs>:  JingleSessionPC[session=JVB,initiator=false,sid=7pmf7t58qqr3f] Switching video codec from vp9 to vp8
Logger.js:154 2022-03-07T17:26:23.322Z [modules/xmpp/JingleSessionPC.js] <Qr.setVideoCodecs>:  JingleSessionPC[session=JVB,initiator=false,sid=7pmf7t58qqr3f] Queued setVideoCodecs task
Logger.js:154 2022-03-07T17:26:23.875Z [modules/xmpp/JingleSessionPC.js] JingleSessionPC[session=JVB,initiator=false,sid=7pmf7t58qqr3f] setVideoCodecs task is done
Logger.js:154 2022-03-07T17:28:13.664Z [modules/xmpp/JingleSessionPC.js] <Qr.setVideoCodecs>:  JingleSessionPC[session=JVB,initiator=false,sid=7pmf7t58qqr3f] Switching video codec from vp8 to vp9
Logger.js:154 2022-03-07T17:28:13.664Z [modules/xmpp/JingleSessionPC.js] <Qr.setVideoCodecs>:  JingleSessionPC[session=JVB,initiator=false,sid=7pmf7t58qqr3f] Queued setVideoCodecs task
Logger.js:154 2022-03-07T17:28:13.942Z [modules/xmpp/JingleSessionPC.js] JingleSessionPC[session=JVB,initiator=false,sid=7pmf7t58qqr3f] setVideoCodecs task is done
Logger.js:154 2022-03-07T17:28:18.875Z [modules/RTC/TraceablePeerConnection.js] <new Ba>:  Using RTCRtpTransceiver#setCodecPreferences for codec selection
Logger.js:154 2022-03-07T17:28:18.986Z [modules/xmpp/JingleSessionPC.js] <Qr.setVideoCodecs>:  JingleSessionPC[session=P2P,initiator=false,sid=64d1b7a142cd] Switching video codec from vp8 to vp9
Logger.js:154 2022-03-07T17:28:18.986Z [modules/xmpp/JingleSessionPC.js] <Qr.setVideoCodecs>:  JingleSessionPC[session=P2P,initiator=false,sid=64d1b7a142cd] Queued setVideoCodecs task
Logger.js:154 2022-03-07T17:28:19.016Z [modules/xmpp/JingleSessionPC.js] JingleSessionPC[session=P2P,initiator=false,sid=64d1b7a142cd] setVideoCodecs task is done

Thanks for the info @jallamsetty.

We’ve actually seen no p2p with two iOS devices as well. Let’s see if that’ll be the case on the latest version.

Meantime, what would be the best configuration for enabling a fallback to VP8 as needed? I see in your logs the following line, which, I assume, should force VP9 even if there are just two iOS devices in a conference (resulting in no video on both)?

2022-03-07T17:25:57.817Z [modules/RTC/CodecSelection.js] <new So>:  Codec preferences for 
the conference are JVB: vp9,  P2P: vp9

The fallback to VP8 is the default behavior unless specifically forbidden through the config parameter enforcePreferredCodec.

1 Like

Thats the preference expressed through config.js but the negotiated codec will be based on what is preferred and what is supported. Also, fallback to VP8 is the default behavior unless it is explicitly overridden as Freddie mentioned.

Thanks for the explanation!. As enforcePreferredCodec resides in a different section of config.js I didn’t realize that it applies to P2P as well.

As for cross-browser P2P, should we expect it between Chrome on Android and Chrome on Desktop?

Chrome on Android and Chrome on desktop is the same browser and therefore p2p will be enabled for that call. Whenever, there is one Safari/Firefox client involved, p2p will be automatically disabled. Please note that Chrome, Firefox or any other browser on iOS will still be considered as Safari since they all use WebKit WebView.

Thank you @jallamsetty ! Do you know if there’s any timeline for a fix on WebKit side?

I’ll need a few days to arrange update to the latest version of Jitsi on our side. I was going to ask if a new version is planned anytime soon, but as I see there’s stable-7001 published on docker hub a few hours ago. So we’ll use that one and I’ll post our findings here when they’re ready.

Once again, thanks for your help!

@nickr_swp What fix are you referring to ?

@jallamsetty The one that would allow P2P connection between Safari users.

This is not a browser limitation. We have disabled cross browser p2p since there are BWE issues. Safari especially only sends the lowest spatial layer over the p2p connection even when higher resolutions are requested.

ETA: What I meant in the previous post is that Chrome on iOS is essentially Safari browser. Therefore, the media for a call between Chrome on web and Chrome on iOS will still go through jvb.

Thanks for clarification @jallamsetty !

We’ve not updated to the latest version of Jitsi yet. I’ll let you know my findings when that’s done.