One of my main goals recently is to improve Jitsi by adding proper VP9 support across the board. I’m aware I’m mad, yes.
There appear to be several pieces that are not fully assembled, and a few parts I haven’t actually worked out the details on yet that I would appreciate feedback on.
If you force Jitsi to use VP9, by setting
org.jitsi.jicofo.ENABLE_VP9=true in /etc/jitsi/jicofo/sip-communicator.properties (and disabling VP8/H264), it more or less works. But this requires disabling the other codecs, and it doesn’t offer “proper” support.
I’ve added (in my branch, haven’t finished poking so it’s not pushed up yet) “preferVP9” support in the style of preferH264 support, and this seems to work fine for P2P connections. I think getting this working should be fine, though it would still require server configurations to enable (I don’t think enabling VP9 by default is the right option, see below).
Non-simulcast VP9 should be fairly straightforward as well, though I’m not quite there. Simulcast VP9 support will require jvb updates, though there’s a PR for jvb1 that enables most of the support - I’ll figure out how to port this to jvb2’s code, and it looks like some fairly minor changes to properly handle keyframe support. In theory.
However, there are still some issues related to VP9 that I don’t fully understand how to address.
The first is that if a client joins a bridge and doesn’t support VP9, the system should fail back to VP8. I’m unclear as to if this is a theoretical issue in the “Should do at some point…” range, or an actual issue that needs to be addressed for the feature to be at all useful. I know halfway recent Chrome browsers support VP9 (it was added around v48), and experimenting with mobile devices indicates they do support VP9 as well.
The second, (IMO) more important issue is that some client systems, especially lower power ones, simply cannot encode to VP9 at a good resolution/framerate. I’ve got an older Chromebook that can do it, but at a very low framerate - there’s no hardware support and not enough CPU support to encode at a useful quality. For this system, VP9 is actively worse than VP8, because of the reduction in output quality from being CPU limited. It might be possible to detect that a tab is pegging a CPU and drop back to VP8, or it might be possible to identify if a platform has hardware VP9 support. Or allow users to select, but this seems less than helpful.
Any suggestions on either of these would be appreciated. I’ve got time to throw at the project, and am already deep in the related code chunks. Is there anything else obvious I’m missing?