Flagship VP9 Support: Notes and Discussion

Yes, right under preferredCodec

preferredCodec: 'VP9' ,
enforcePreferredCodec: true,

Aaaah see, like I said, won’t be the first time. I didn’t make videoquality active. :man_facepalming:t5: One sec.

So let me tell you what I see:

I have 4 users - 3 on chrome (just tabs) and one on Safari. With the enforcePreferredCodec enabled, the 3 Chrome tabs show all four particpants, 3 of them (chrome) on VP9 and one of them (Safari) on VP8. Now, I know this wasn’t your intended behavior, BUT I LOVE IT!!! :joy:

On the Safari client though, the other users are not visible (the tiles are shown and Safari is in the meeting). Interestingly, before I refreshed (for the umpteenth time), on Safari, I actually saw 2 of the Chrome clients… lol

Actually it is the intended behavior. Chrome can decode VP8 from Safari because it supports both VP8 and VP9. It is the other way around that doesn’t work, i.e., Safari won’t be able to decode VP9 from Chrome.

1 Like

Oooooh awesome! My understanding was that once Safari joins the call, everyone gets downscaled to VP8. But that’s not what I’m seeing. I like what I’m seeing though, so don’t try to ‘fix’ it… lol

Thank you for the awesome work you do and for your responsiveness!


Hello @Jonathan_Lennox
Is VP9 merged to jitsi-videbridge repo? I can see a commit VP9 support but at the same time your branch is still 119 commits ahead of master hence asking this question.

@Freddie WDYT? I’m confused here.

Yes, it is merged!

It was a squash merge, so my branch will have a bunch more commits than master.

Please let me know any odd behavior your see.

1 Like

Thanks a lot for the info

Sure :slight_smile:

@Jonathan_Lennox Just built off of the master in the main repo (both media-transform and JVB fat jar). Could be something I’m doing wrong, but I’m not seeing the resolution and bandwidth savings I see in my older implementation of VP9.

My simple test is the presence (or absence) of HD resolution in tile view. In my older implementation, tile defaults to HD with VP9. In the current JMS version also with the non-merged VP9 JVB, tile defaults to HD if I make the Jicofo changes to allow VP9 (but of course, JVB is not doing any VP9 forwarding).

If I’m doing something wrong, kindly advise.

Can someone confirm we no longer need to bake Jonathan’s jar to get fully working VP9 on the bridge?

Can we now just install the unstable packages and it should work out of the box?



You’ll need to edit the jicofo config file to enable VP9 support, but all the packages should work out of the box, yes!

1 Like

Will there eventually be a way to prefer VP9 through jitsi-meet’s config? It seems, at the moment, the preferred codec state does not enable VP9.

You can set it through the Jicofo config, if you’re running your own backend. There’s no way for the jitsi-meet client to unilaterally prefer VP9 if Jicofo isn’t configured to negotiate it.

we installed latest unstable, and hurray, VP9 works and is incredibly hot.
Thanks a lot, guys, your work on jitsi throughout this last year has been and is fantastic!!!

However, i am having a hard time getting all the needed information together, and i think we might still have an issue with VP8 fallback here.
in two of the sessions we started, since the upgrade, it was not possible to connect to anyone but myself. Everybody can see themselves, but not hear or see anyone else.
I suspect some participant not being able to use VP9, and as VP8 fallback maybe isn’t working, we see these issues now.
Please correct me if i’m wrong, and this has nothing to do with each other.

So basically if i would want to get everything running, what else would i have to do.
What we actually did is:

  • Update to latest unstable (Monday)
  • Add preferredCodec: ‘VP9’, to /etc/jitsi/meet/foo.bar-config.js

that’s pretty much about it.
I read about something i needed to add to jicofo config, but not really sure what or where.
Also read about enforcePreferredCodec, but also don’t really know where or how.

Thanks a lot for your assistance!

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',


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


@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