What’s the quality? WebRTC generally tries to use the full available bandwidth, but it should look better with VP9 by a large margin.
looks pretty good. just noticed higher bitrate, which I found strange. maybe its more to do with simulcast not working with vp9? I guess I was expecting much lower bitrate than with vp8 and h264. I’ll run some more test
Without a way to tell WebRTC to target a quality, it will fill the channel up to some reasonable limit.
On my list of things to figure out is how to specify quality, or at least set a custom bandwidth limit. My connection isn’t exactly amazing, and I’d prefer to be able to use less of the connection.
For now jitsi implements minBitrate only on jicofo side.
I recommend you to modify lib-jitsi-meet SDP management part to add webrtc bandwidth limiters
I can confirm, chromium based browsers (chrome, brave, opera, new edge, vivaldi) since version 48 and firefox browser since version 46 support VP9. Safari does not support VP9 and recently added support to VP8. So all OS (GNU/Linux, Windows, macOS and Android) are covered with the exception of iOS that does not support a different browser than safari (all the others are safari browser with a different UI).
Regarding the hardware, practically all the modern SoC and video card have VP9 encoding/decoding capabilities. Moreover, if they do not have encoding capabilities, as common, they could use software implementation via CPU SIMD instructions.
Regarding to bandwidth, VP9 allows to save up 40% of it compared to VP8 at the same quality.
Yes, this is my plan. I’d like to be able to have an “advanced” interface that allows one to simply specify parameters - min, max, or “Aim for this bitrate, yes, I know, your estimation says it won’t work, I say it will, just bloody well do it.”
My experience with an older Chromebook is that it struggles with VP9 encoding, but it will do it. I’ve not tested it over low bandwidth links.
Unfortunately, it’s nice out, and this is my rainy day project right now, until I get a few other things finished around the property.
Any update on this? Really looking forward to seeing VP9 working in jitsi!
I think it will improve the UX immensely
Hi VP9 enthusiast and @Jonathan_Lennox,
I learnt that Intel’s SVT-VP9 is soo blazing fast and been memory-efficient that they could retire x264 or (has been proven to be retired) google’s libvpx-VP9 decently. They have adopted the encoder in their simple WebRTC project as well here: https://github.com/OpenVisualCloud/Video-Conferencing-Sample . The patch for FFMPEG is available for service here https://github.com/OpenVisualCloud/SVT-VP9/tree/master/ffmpeg_plugin.
All you have to do only by recompile or patch the distro’s FFMPEG and switch current libvpx VP8 or VP9 with libsvt_vp9 or make another fallback with libsvt_vp9 just for test.
I love to see Jitsi can use Intel’s matured VP9 software encoder for RTP payload’s codec and Jibri’s x11grab as well (and maybe someday also with SVT-HEVC, that this still considered too young at the moment)
Weather’s too good lately, I’ve been working on solar installs. Sorry, no updates! Supposed to be some worse weather later this week. But VP9 generally seems to work at a basic level.
I don’t think the encoding system is really something Jitsi can pick, though. Wouldn’t it be up to the browser?
Right and above all this is not the biggest problem. As I wrote previously, modern SoC and video card have both VP9 encoding/decoding capabilities. Decoding and encoding performance of various CPU. The decoding phase is practically negligible (up to full hd 1080) for CPU released later than 2012 while the encoding requires more modern CPU 2016+ (on full hd 1080).
I believe most browsers already support VP9 but not sure it’s offered yet in the WebRTC SDP.
Regardless, as long as the browser supports VP9 we should be able to change the SDP on the jicofo side and force VP9, no?
You can force VP9 with jicofo config options, but I’m not sure this is always the right option - clients should be able to fall back, and that would prevent clients that don’t have VP9 support from doing anything at all.
It appears Jonathan is doing some VP9 SVC support plumbing in the jitsi-transform libs, so I’m inclined to wait until that’s done and see how it works. I’m crazy enough to work on this, but I’m not particularly good at the web/Java side, as my expertise is far lower level.
Hey guys any new update on this topic
As here in india we guys also have the same bandwidth problem and are trying to optimize our server for network so that users with low bandwidth may still use it.
And i found that using vp9 would be a great option for that.
Are there any better ways for optimizing bandwidth for my clients
I’m looking for VP9 too, Microsoft teams use VP9 and the quality and networks usage is perfect.
How can we enable VP9 in jitsi easily please ?
I’d be willing to donate some money towards the cause if the right developer for the job is available, but needs to fund the work (not being an active developer myself)
At this point, I’m happy to leave it to the core developers. I’ve made some changes, submitted some code, and… crickets. I’ve been trying to do bugfixes and documentation updates as well and the PRs just linger, uncommented on and not merged. So I’m uncertain as to how one ought to actually develop for the project as an external third party. Sorry!
you may need ot push the PR upstream to get the devs attention and any feedback… You’ll also likley need to sign the cla (contributor-license-agreement)
Please don’t give up @Syonyk. The community appreciates your effort and it will be great to have VP9 support in Jitsi.
Also as speedy01 says make sure you sign their cla
The PRs are linked in the various jitsi repos, and I’ve signed the CLA. Some of my PRs have been merged, but the rest linger and I’ve no idea how to either get a “This is why we’re not merging it” response or them merged. I’m not highly motivated to drag out old web skills and learn new frameworks if the work is simply going to linger. Jonathan is doing at least some work with the VP9 parsing on the videobridge side.