Hi, does moving to VP9 help reducing client CPU usage?
I doubt it. Probably the opposite actually since VP9 is a lot more CPU intensive.
Now I am confused.
What does @Syonyk’s commit to jitsi-meet config,js options do ? Doesn’t that commit allow you to enable vp9 because the lib-jitsi-meet commit picks up that option ?
And must I disable simulcast to use VP9 ? Isn’t that a bad trade ?
From my understanding his commit is to allow the option in the config as VP9, similar to h264. BUT this isn’t in jitsi-meet’s main branch, so unless your running his specific commit of lib-jitsi-meet code the
preferVP9:true won’t do anything in your config in
IIRC I had better results removing simulcast. Simulcast I assume uses more bandwidth as you are sending multiple streams. Test what works for you.
Hi VP9 fan,
I would like to enable VP9, can you show me steps to achieve it?
I have this option enabled:
how about reading the discussion
How to disable simulcast ?
set disableSimulcast: true,
in the /etc/jitsi/meet/yoururl-config.js
mind you, I’m not even certain that it’s needed.
I enabled VP9 (as described above ) and I made small and short test:
1 desktop sharing +3 video call+1 audio call the result as blow
Before enabling VP9
After enabling VP9
VP9 consumes more bandwidth! I didn’t see any enhancement.
@Yassine If I understand the results you displayed, it looks like it dropped your receive bandwidth but increased transmit bandwidth.
Yes, 3 times increased
Is it possible that the client is sending multiple streams with different resolutions for simulcast instead of using VP9 SVC, therefore increasing both the required bandwidth and CPU for TX?
VP9 with SVC is superior than using simulcast. I don’t know what is the complexity involved on the JVB side to support SVC, but I believe that this is the way to go. Moreover, there should be an option to force VP9 with SVC only.
I’m quite sure that there are many people like me looking at these Jitsi VP9 threads to see if Jitsi will be able provide an on-prem solution that falls near Teams/Meet performance (Zoom performance is superior than there two).
Keep in mind though that you will need more than that to replace the feature rich teams.
Integration with storage/office/calendars and permission management like AD
We have Teams but we would like an on-prem solution to be used with Mattermost.
Here is my take on compairison between VP8 and VP9.
The 2 tests are done with the same hardware
a VPS hosting 2 containers, one with last stable Jitsi-meet (2.0.4627-1) for VP8, and one with last instable Jitsi (2.0.4682-1)
The 2 stations used are the same and the measures are done on the same station.
The connexion is a low end ADSL connection (900 kb upload / 15 Mb download) so a very constrained configuration (since the 2 computers are sharing this very low upload bandwidth)
The following numbers come from Chrome://webrtc-internals
|timestamp||01/06/2020 à 16:02:28||01/06/2020 à 16:16:21|
|[codec]||VP8 (100)||VP9 (101, profile-id=0)|
|timestamp||01/06/2020 à 15:50:12||01/06/2020 à 16:29:56|
|[codec]||VP8 (100, x-google-start-bitrate=800)||VP9 (101, x-google-start-bitrate=800)|
Can be seen in the stats: higher resent packets in VP8, lower number of frames for the same data (10 Mbytes) translate in clearly smoother video for VP9. Obviously I could not talk to myself so I can’t judge sound.
Not seen in the stats:
VP8: first time quality started higher than for VP9 but after a few moments I realized that Jitsi-meet had frozen the updates on the other station. Another test crashed one station. Yet another test crashed the other station.
Vp9: the test was repeated 2 times and went without problem with a constant (low but with this bandwidth it could hardly be good) quality except for the few first seconds.
The worse quality was seen with VP8 when it worked on one of the 2 stations, the other station was level with the VP9 quality.
Yesterday I looked at the VP9 bandwitdh with a more realistic example, a meeting with 2 persons having a normal bandwidth for this time (that is 4-8 Mbits upload): I saw a very decent quality and the sound was good, no jerky animation, no sound distortion for about one hour. On my VPS the stats of my hosting provider rated the bandwidth at 4,2 mbits/s, that is 1.4 Mbits average per user.
By and large I am very satisfied with VP9. I used to disable simulcast with VP8 to get decent quality but with VP9 I get equivalent quality but with lower bandwidth as measured by Jitsi-meet.
Note that with VP9 I always see the connection quality as ‘mediocre’ in the Jitsi UI. I suspect there is a problem at this level when used with VP9 because the observed result is in fact good.
Also I did a quick test with an very limited Android phone and it works with VP9 but it is turning it into a hand warmer and autonomy would probably take a big hit.
VP9 would be even better if it was possible to use it configured from the URI instead of Jicofo and as such used only by stations that could take full advantage of it. But as it is I’m pleased with it.
Thanks for the detailed feedback.
Looks like VP9 is coming along nicely.
These are similar to my results as well, VP9 I can push an NDI 1080p stream and the quality is really good at 30fps. Even with some clients over wireless, it seems to hold really well.
Thanks @gpatel-fr for posting your results.
Great work, Thanks.
Just be clear: is simulcast disabled in both ?
As I understand it, simulcast has no sense with VP9 and with VP8 I have found that somehow enabling simulcast lowers quality even in case that don’t warrant it - probably a bug I suspect.
well there is some work to do, unfortunately not all from the jisti point of view; I have done a quick test with Firefox and it definitely does not like VP9.