Flagship VP9 Support: Notes and Discussion

The only settings for it is having preferredCodec: ‘VP9’ for p2p and ing the general section (for jvb) in config.js and the other is having it enabled in jicofo which is the case by default: jicofo/reference.conf at d9ee56e37c4c1b7f8cfd9e7b418b8fb9cf2938ff · jitsi/jicofo · GitHub

Nice job with adding VP9 support @Jonathan_Lennox and the rest of the team.

Few observations from my side after testing :

1- There seem to be a slight video drop moving from P2P and Multiparti call and vise versa, noticed this testing over chrome.
2- iOS download seems to be in pixelated SD. “Browser”
3- Same for iPad Mini and a Brand new iPAD Air, SD download and degradtion in video quality. “With VP8 both working fine”.
4- iOS jitsi app shows low quality receive feed.
5- Android chrome browser, download feed permanently freezes frequently, have to refresh tab to rejoin (upload still sends whilst download freezes).

1 Like

Hi damencho, thanks a lot for your reply.
So, if i understood you correctly in our /etc/jitsi/meet/foo.bar-config.js, we would have:

p2p: {
    enabled: true,
    preferredCodec: 'VP9',

and

videoQuality: {
preferredCodec: 'VP9',

nothing else? No need to explicitly tell jitsi it should fallback to vp8 if anything does not work with VP9?

Also my jicofo.conf looks very much different:

/etc/jitsi/jicofo/jicofo.conf :

jicofo {
xmpp: {
client: {
client-proxy: focus.foo.bar
}
}
}

Do i have to replace this with something more similar to jicofo/reference.conf at d9ee56e37c4c1b7f8cfd9e7b418b8fb9cf2938ff · jitsi/jicofo · GitHub

thanks
Sascha

@Jonathan_Lennox in addition to this. For point 5 with the Android Chrome browser I tested on https://beta.meet.jit.si/csq123 today if you want to check the call logs. For the android devices I was testing on 2x Samsung Galaxy Tab A8 and 1xSamsung Galaxy A21s. Admitedly not particularly powerful devices, but didn’t freeze download streams on VP8 but does on VP9. Thanks

Fallback to VP8 is the default behavior when an endpoint that doesn’t support VP9 joins the call.

Hi @jallamsetty , thanks for your answer, this helps a lot!

However we still have some issues with the new unstable version, which i hope you would have some ideas for.
first of all, if i understood it correctly, we’re supposed to enable preferredCodec: ‘VP9’ in the p2p section as well, so this is what we did:

p2p: {
    enabled: true,

    useStunTurn: true,

    stunServers: [

        { urls: 'stun.1und1.de:3478' },
        { urls: 'stun.t-online.de:3478' },
        { urls: 'stun.nextcloud.com:443' },

    ]

    // iceTransportPolicy: 'all',

    // preferH264: true

   preferredCodec: 'VP9',

    // disableH264: false,

    // disabledCodec: '',

    // backToP2PDelay: 5
},

But as sson as we activate the preferredCodec: 'VP9', line, the jitsi login page will not appear anymore.
Only a grey empty page will be shown.
So for now, we just commented that part out and jitsi works again.
What are we missing?

Also, with the new unstable version of jitsi, Android clients, using the latest jitsi app (21.0.0), can not join any meetings.
With the version before (20.6.2) it works perfectly again.
Any clue?

thanks fpor your great support
Sascha

@tafkaz
The “preferredCodec” line has a trailing comma ‘,’, which violates the JSON format.

Delete the trailing comma and it should be working fine…

Hi,
no that didn’t help:

// Provides a way to set the video codec preference on the p2p connection. Acceptable
// codec values are 'VP8', 'VP9' and 'H264'.
preferredCodec: 'VP9'

same grey login screen.

Also i think we need the trailing comma, as this is exactly the same here:

videoQuality: {
preferredCodec: ‘VP9’,

any more clues?
thanks
Sascha

@tafkaz It needs to be enabled inside the p2p block; you’re enabling it outside.

p2p: {
enabled: true,
preferredCodec: ‘VP9’,
},

Hi @Freddie

as i thought i had everything in the p2p block:

p2p: {
    enabled: true,
    useStunTurn: true,
    stunServers: [
        { urls: 'stun.1und1.de:3478' },
        { urls: 'stun.t-online.de:3478' },
        { urls: 'stun.nextcloud.com:443' },
    ]
   preferredCodec: 'VP9',
},

i was not sure.
But yes…actually changing it to:

p2p: {
    enabled: true,
    preferredCodec: 'VP9',
    useStunTurn: true,
    stunServers: [
        { urls: 'stun.1und1.de:3478' },
        { urls: 'stun.t-online.de:3478' },
        { urls: 'stun.nextcloud.com:443' },
    ]
},

did the job, thanks a ton!

cheers Sascha

Last issue then:

I hoped for a relief, after getting VP9 for p2p running, but unfortunately, this problem persists.
Is this a known bug in the latest Android App Version maybe, i can’t find anything about it.

thanks
Sascha

We have not tested VP9 support on mobile yet.

@saghul i see, but:

  • Shouldn’t it fall back to VP8 if it fails with VP9, and
  • Why would the penultimate version (20.6.2) work splendidly (with VP9) then?

The latest App version would simply not let you in at all here.

thanks
Sascha

Hard to tell without any logs. adb logact would help here.

Hi @saghul
must admit, i am not very familiar with adb.
I tried with “Android Terminal Emulator” by Jack Palevich, opened it and typed “logcat”.
the log starts to run.
Now i try to enter a room via the jitsi app, but although i get a time out message after around 30 seconds, the logs don’t show anything in the meantime.
It looks like logcat only responds to my selections on the display, not on anything in the app.
If you maybe could point me to some parameters for that command or tell me what else i could try, i would be very keen to send you some logs.

thanks
Sascha

The simplest is to use this: GitHub - JakeWharton/pidcat: Colored logcat script which only shows log entries for a specific application package. and run it as follows: pidcat org.jitsi.meet

That will filter the output to just Jitsi Meet.

Hi @saghul and others,

problem solved here:

Sorry, but since we have a historically grown instance, we seemed to have missed that one.
Thanks for your help
Sascha

Good to hear!

In addition to an extra comma after preferredCodec, you lack one after the stun array.

More precisely:
The bandwidth estimation seems to be broken (for all codecs) when you disable COLIBRI_WEBSOCKET. Don’t do this!
I had done so, because I could not possibly get XMPP_WEBSOCKET to work.
The good news is that those two are truely independent and COLIBRI_WEBSOCKET seems painless.
See Broken bandwidth estimation in stable-5765-1 (websockets disabled) - #3 by garloff .