Flagship VP9 Support: Notes and Discussion

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 /etc/jitsi/meet/EXAMPLEdomain.cfg

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:
enableLayerSuspension: true,


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.

1 Like

@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


variable vp8 vp9
timestamp 01/06/2020 à 16:02:28 01/06/2020 à 16:16:21
ssrc 3880141554 3559169872
isRemote false false
mediaType video video
kind video video
trackId RTCMediaStreamTrack_receiver_8 RTCMediaStreamTrack_receiver_4
transportId RTCTransport_audio_1 RTCTransport_audio_1
codecId RTCCodec_video_Inbound_100 RTCCodec_video_Inbound_101
[codec] VP8 (100) VP9 (101, profile-id=0)
firCount 0 0
pliCount 3 0
nackCount 27 22
qpSum 538527 1906826
[qpSum/framesDecoded] 45.8 126.56666666666666
packetsReceived 13190 15847
[packetsReceived/s] 30.002861295823653 28.011774243829695
bytesReceived 10032744 10010994
[bytesReceived_in_bits/s] 229773.91294793587 54895.07415383654
headerBytesReceived 316560 380328
[headerBytesReceived_in_bits/s] 5760.549368798142 5378.260654815302
packetsLost 1 0
lastPacketReceivedTimestamp 1575.48 2408.49
framesDecoded 9523 14712
[framesDecoded/s] 15.001430647911826 30.012615261246104
keyFramesDecoded 11 10
totalDecodeTime 54.751 41.561
[totalDecodeTime/framesDecoded_in_ms] 6.13333333333325 2.3000000000000873
totalInterFrameDelay 475.583 557.635
[totalInterFrameDelay/framesDecoded_in_ms] 66.86666666666952 33.36666666666588
totalSquaredInterFrameDelay 47.9796 25.9355
[interFrameDelayStDev_in_ms] 1.4772346535337413 2.5817737227734123


variable vp8 vp9
timestamp 01/06/2020 à 15:50:12 01/06/2020 à 16:29:56
ssrc 2782438328 2218009605
isRemote false false
mediaType video video
kind video video
trackId RTCMediaStreamTrack_sender_2 RTCMediaStreamTrack_sender_4
transportId RTCTransport_audio_1 RTCTransport_audio_1
codecId RTCCodec_video_Outbound_100 RTCCodec_video_Outbound_101
[codec] VP8 (100, x-google-start-bitrate=800) VP9 (101, x-google-start-bitrate=800)
firCount 0 0
pliCount 8 6
nackCount 39 24
qpSum 1034678 2969745
[qpSum/framesEncoded] 52.266666666666666 156.93333333333334
mediaSourceId RTCVideoSource_2 RTCVideoSource_4
packetsSent 17380 18195
[packetsSent/s] 31.652429592669115 29.977814880040253
retransmittedPacketsSent 100 24
[retransmittedPacketsSent/s] 0 0
bytesSent 10092882 10016928
[bytesSent_in_bits/s] 239379.41190195834 85288.88185470652
headerBytesSent 419808 447432
[headerBytesSent_in_bits/s] 6077.26648179247 5755.740456967728
retransmittedBytesSent 26977 20690
[retransmittedBytesSent_in_bits/s] 0 0
framesEncoded 16327 17262
[framesEncoded/s] 29.674152743127294 29.977814880040253
keyFramesEncoded 17 14
totalEncodeTime 210.509 279.861
[totalEncodeTime/framesEncoded_in_ms] 20.53333333333285 11.733333333332515
totalEncodedBytesTarget 10611150 10700730
[totalEncodedBytesTarget_in_bits/s] 265160.31580518733 94514.05475379092
totalPacketSendDelay 359.56 490.894
[totalPacketSendDelay/packetsSent_in_ms] 22.999999999999687 17.499999999999243
qualityLimitationReason bandwidth bandwidth
qualityLimitationResolutionChanges 0 0

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.

1 Like

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.

1 Like

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.