I get regular requests and issues have been raised about upgrading the Jitsi meet code in the Openfire Pade plugin to the latest versions. Unfortunately, this task is much more difficult than it sounds.
Jitsi Meet has evolved a lot since the early days of WebRTC. It has moved from being a Java platform agnostic, XMPP compatible self-hosting application into a Linux cloud hosted service.
The current code still depends on our Smack project for the XMPP client, but it uses Prosody as the XMPP server with quite a few extensions and modules coded in Lua which need to be ported to Java. Apart from not having time to work on it, I have also lost the motivation to step up to the challenge as I am more interested in using WHIP and WHEP with XMPP.
Nevertheless, an issue can round last week requesting for support of AV1 codec. This sparked enough motivation for me to spend my Easter holidays trying one more time to make the upgrade happen. The bad news is that I failed yet again, but the good news is that I was able to update the existing code to support AV1. Please note that codecs have pros and cons. VP9 is probably the best all rounder. H264 is best with devices that have hardware encoders and AV1 handles low bandwidth the best.
Openfire Pade plugin version 1.8.4 now supports the AV1 codec. You get the best results with P2P calls. As it is it more CPU intensive than VP9, you make get lower frame rates on low-spec servers. The latest Jitsi code has a lot more improvements and if you really need AV1 with many participants, seriously consider deploying the Jitsi Meet self-hosted instance in a container or VM.
As always, your instance of Openfire should automatically make available to update. Alternatively, you can download the new release of the plugin at the Openfire Pade plugin’s archive page.
For other release announcements and news follow us on Mastodon or X
2 Likes
First: we really like the Openfire Pade solution. It is a wonderful, private label, very secure solution for us and our clients, running on Fedora VMs with 8Gb RAM.
Second: we are ‘application development’ people and would not begin to suggest that we fully (or even remotely) understand the benefits of ‘AV1 codec’ support of of ‘WHIP and WHEP with XMPP’.
However, when we updated Pade one of the Openfire servers, and used the configuration suggestion to ‘Force AV1 codec’, we noticed a definite lag in video sync among the users. This was resolved by unselecting ‘Force AV1 codec’, but we’re left wondering if this is the expected result’.
We saw the documentation: ‘Please note that codecs have pros and cons. VP9 is probably the best all rounder. H264 is best with devices that have hardware encoders and AV1 handles low bandwidth the best.’ but we’re not sure how to interpret this.
Again this is NOT a complaint. Openfire-Pade is working splendidly. Just looking for some direction.
Thank you for the kind words 
If you want the best video latency (high framerate) like watching a video and you are on a LAN with plenty of bandwidth on your network for all your users then deselect both Force AV1 and Force VP9. Jitsi will default to H264 which has hardware encoders/decoders on most laptops and phones and gives best performance provided you have the bandwidth on your network.
If your users are on the Internet with bandwidth restrictions, then Force VP9 gives the best results with bandwidth restrictions. However, hardware encoding/decoding is not as available as H264. It also does not handle low bandwidth as good as AV1.
If you have very limited bandwidth, Force AV1 gives better results than VP9, but uses more CPU on the server and may create latency as you have experienced.
This is excellent Dele. Thank you.
We have a ‘fairly fast’ network internally, however if I understand you correctly … we should plan to ‘force a codec’ as necessary to to provide the best experience for the widest range of our expected audience.
Most of our ‘audiences’ are other business users with ‘fairly fast’ internal networks. Its good to know that we have options to better address the needs of home users … or ‘working from home’ users.
Thank you again.
