Screensharing Crashing when using VP9

We have been running VP9 since it was available in unstable and its been working pretty well. Unfortunately it seems there is a new bug that only happens when using chrome and VP9. If everyone in the meeting is on Chrome/Chromium and we all are using VP9, whenever an individual starts to screenshare, their browser tab crashes. Switching the preferredCodec to VP8 or someone joining from safari/firefox eliminates the issue. It might have to do with the bit rate settings but not seeing evidence of that. Also this started on an earlier version and I upgraded to see if it would stop so I think it may be related to the issues Chrome has introduced with the latest version.

Chrome Build 92.0.4515.107 64 bit
jitsi-meet: 2.0.6119-1
prosody: 0.11.9-1~focal1
jicofo: 1.0-773-1
jvb: 2.1-533-g2703e2d0-1

     videoQuality: {
        preferredCodec: 'VP9',
        maxBitratesVideo: {
            low: 200000,
            standard: 500000,
            high: 1500000
        },
        minHeightForQualityLvl: {
            360: 'standard',
            720: 'high'
        },

JVB Logs:

JVB 2021-07-29 16:09:00.694 INFO: [22] VideobridgeExpireThread.expire#140: Running expire()
JVB 2021-07-29 16:09:00.706 INFO: [23] HealthChecker.run#171: Performed a successful health check in PT0S. Sticky failure: false
JVB 2021-07-29 16:09:01.456 INFO: [2142] [confId=53cbe3697ce40b1f gid=112874 conf_name=mymeeting@conference.jitsi.testing.net] Conference.dominantSpeakerChanged#424: ds_change ds_id=afc9a45e
JVB 2021-07-29 16:09:02.898 INFO: [2145] [confId=53cbe3697ce40b1f gid=112874 stats_id=Verda-3t3 conf_name=mymeeting@conference.jitsi.testing.net ufrag=7f2sq1fbpfl0p0 epId=3a8f71f5 local_ufrag=7f2sq1fbpfl0p0] ConnectivityCheckClient.processTimeout#860: timeout for pair: 10.20.20.20:10000/udp/srflx -> 10.10.10.10:45355/udp/prflx (stream-3a8f71f5.RTP), failing.
JVB 2021-07-29 16:09:05.898 INFO: [2145] [confId=53cbe3697ce40b1f gid=112874 stats_id=Verda-3t3 conf_name=mymeeting@conference.jitsi.testing.net ufrag=7f2sq1fbpfl0p0 epId=3a8f71f5 local_ufrag=7f2sq1fbpfl0p0] ConnectivityCheckClient.processTimeout#860: timeout for pair: 10.20.20.20:10000/udp/srflx -> 10.10.10.10:45355/udp/prflx (stream-3a8f71f5.RTP), failing.
JVB 2021-07-29 16:09:08.058 INFO: [2142] [confId=53cbe3697ce40b1f gid=112874 conf_name=mymeeting@conference.jitsi.testing.net] Conference.dominantSpeakerChanged#424: ds_change ds_id=b000464a
JVB 2021-07-29 16:09:08.898 INFO: [2145] [confId=53cbe3697ce40b1f gid=112874 stats_id=Verda-3t3 conf_name=mymeeting@conference.jitsi.testing.net ufrag=7f2sq1fbpfl0p0 epId=3a8f71f5 local_ufrag=7f2sq1fbpfl0p0] ConnectivityCheckClient.processTimeout#860: timeout for pair: 10.20.20.20:10000/udp/srflx -> 10.10.10.10:45355/udp/prflx (stream-3a8f71f5.RTP), failing.
JVB 2021-07-29 16:09:10.706 INFO: [23] HealthChecker.run#171: Performed a successful health check in PT0S. Sticky failure: false
JVB 2021-07-29 16:09:11.658 INFO: [2140] [confId=53cbe3697ce40b1f gid=112874 conf_name=mymeeting@conference.jitsi.testing.net] Conference.dominantSpeakerChanged#424: ds_change ds_id=afc9a45e
JVB 2021-07-29 16:09:11.898 INFO: [2145] [confId=53cbe3697ce40b1f gid=112874 stats_id=Verda-3t3 conf_name=mymeeting@conference.jitsi.testing.net ufrag=7f2sq1fbpfl0p0 epId=3a8f71f5 local_ufrag=7f2sq1fbpfl0p0] ConnectivityCheckClient.processTimeout#860: timeout for pair: 10.20.20.20:10000/udp/srflx -> 10.10.10.10:45355/udp/prflx (stream-3a8f71f5.RTP), failing.
JVB 2021-07-29 16:09:14.898 INFO: [2145] [confId=53cbe3697ce40b1f gid=112874 stats_id=Verda-3t3 conf_name=mymeeting@conference.jitsi.testing.net ufrag=7f2sq1fbpfl0p0 epId=3a8f71f5 local_ufrag=7f2sq1fbpfl0p0] ConnectivityCheckClient.processTimeout#860: timeout for pair: 10.20.20.20:10000/udp/srflx -> 10.10.10.10:45355/udp/prflx (stream-3a8f71f5.RTP), failing.
JVB 2021-07-29 16:09:16.759 INFO: [2142] [confId=53cbe3697ce40b1f gid=112874 conf_name=mymeeting@conference.jitsi.testing.net] Conference.dominantSpeakerChanged#424: ds_change ds_id=b000464a
JVB 2021-07-29 16:09:17.898 INFO: [2145] [confId=53cbe3697ce40b1f gid=112874 stats_id=Verda-3t3 conf_name=mymeeting@conference.jitsi.testing.net ufrag=7f2sq1fbpfl0p0 epId=3a8f71f5 local_ufrag=7f2sq1fbpfl0p0] ConnectivityCheckClient.processTimeout#860: timeout for pair: 10.20.20.20:10000/udp/srflx -> 10.10.10.10:45355/udp/prflx (stream-3a8f71f5.RTP), failing.
JVB 2021-07-29 16:09:20.278 INFO: [2142] [confId=53cbe3697ce40b1f epId=d6372c05 local_ufrag=4v3ma1fbpge04m gid=112874 conf_name=mymeeting@conference.jitsi.testing.net ufrag=4v3ma1fbpge04m] Agent.gatherCandidates#622: Gathering candidates for component stream-d6372c05.RTP.
JVB 2021-07-29 16:09:20.281 INFO: [2142] [confId=53cbe3697ce40b1f epId=d6372c05 gid=112874 conf_name=mymeeting@conference.jitsi.testing.net] Endpoint.setTransportInfo#679: Ignoring empty DtlsFingerprint extension: <transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'><fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' required='false'/></transport>
JVB 2021-07-29 16:09:20.707 INFO: [23] HealthChecker.run#171: Performed a successful health check in PT0S. Sticky failure: false
JVB 2021-07-29 16:09:20.898 INFO: [2145] [confId=53cbe3697ce40b1f gid=112874 stats_id=Verda-3t3 conf_name=mymeeting@conference.jitsi.testing.net ufrag=7f2sq1fbpfl0p0 epId=3a8f71f5 local_ufrag=7f2sq1fbpfl0p0] ConnectivityCheckClient.processTimeout#860: timeout for pair: 10.20.20.20:10000/udp/srflx -> 10.10.10.10:45355/udp/prflx (stream-3a8f71f5.RTP), failing.

Yes, this is most likely due to Chrome 92’s web media player restrictions. Any chance you can try on an earlier version of Chrome? You can even download the Electron app and test with that.

The restrictions on Chrome 92 should be lifted by August 3rd, btw. So hopefully, that should take care of the issue on Chrome 92 permanently.

1 Like

@Freddie The older versions of Chrome do still work without issue, sorry I should have included that. What I wasn’t 100% sure on identifying is if this bug was related to the same media player restrictions or something else so I wanted to post this just incase it was related to something else Chrome decided to push without warning. I did just test with Canary and it did not happen so my guess is this should be resolved Aug 3rd as you stated.

if its related to media restriction, it should not have worked even on VP8. Dont you think it may be issue with VP9 and Chrome 92.

Can you start chrome 92 with flag --max-web-media-player-count=1000 and then test it with VP9 and see if it still has problems.

I will try… but even if this works… this solution wont work … we possibly cant tell this to each participant who is likely to present / share screen.

I was able to start chrome with that flag and screensharing on VP9 worked. I confirm the bug still existed on the same computer when I did not use that flag.

Please remove desktopSharingFrameRate from your config file

desktopSharingFrameRate: {
        min: 10,
        max: 15
},