Flagship VP9 Support: Notes and Discussion

Are you sure you have no websocket issues on your system

Good question. And thanks for the response. I’m the semi-technical project lead, not the dev lead. I’ll ask my dev lead.

But, I’m curious… what made you think of websockets as a concern?

Are you referencing the JVB websocket or the websockets for prosody? I only ask because I have just started experimenting with VP9 as the VP8 quality is very poor and want to make sure I have it setup the correct way.

The client sends its capability to the videobridge through websocket on the new implementation. Since you have a bandwidth estimation issue there may be something wrong with the websocket traffic.

JVB websocket

@Omatic when you say “bandwidth estimation is horribly low”, what exactly do you mean? From my experience, the BWE in VP9 implementation, as we have it, is off, BUT it does not at all affect the quality of the streams. The only thing that seems off is that the connection indicator would sometimes signal as non-optimal when in fact the visual quality is amazing. And yes, for SVC to kick in with your VP9 flag, you have to have simulcast turned on (:blush: SVC on VP9 Working Beautifully. How to Check). Disabling simulcast means you’re turning off SVC and gives the exact behavior that you’re reporting. My suspicion is, there’s something else going on.

When I say BWE is horribly low when using jonathan’s PR and simulcast enabled, I mean that I’m on a 1 gigabit wired line and 5142 normal estimates ~3 mbps initially, and rises to 11mbps when fully connected.

But using jonathan’s PR and simulcast enabled, BWE starts at ~3mbps initally and falls to 700 kbps.

It seems to me that the BWE calculation is supposed to use current outbound bps as a base, and then add estimated headroom… and it seems like with simulcast enabled, it’s not reading the current sent bps right, and so the estimated headroom is way off

Right, but I guess my question is: how’s the visual quality? You said the BWE is horribly low, ruining your meetings. Does the visual quality deteriorate with the downscaled BW?

With BWE horribly low, the server is forwarding only the lowest layers of the VP9 feed, so it’s horrible.

I have no doubt something is wrong with our setup… we just can’t figure out what.

Aaaah I get you now.
I wonder what it could be. And I wonder if the incorrect BWE is even the culprit. In my deployment, I restrict the send bandwidth to SD (around 600kbps) and still get 1280x720 HD quality videos. That’s what makes me wonder what could be the problem in your case. Even at 180p resolution, for us, the video quality is still pristine (although I’ve only checked this bit in Tile View).

With just one other participant in the meeting, low BWE doesn’t cause much of a problem. But add 16 participants, and it’s not even possible to do 180p x 7.5fps.

My team switched back to websockets from bosh and early tests suggest that fixed the problem!!! We are now seeing the expected bandwidth estimation with simulcast enabled with VP9 using Jonathan’s PR.

One concern: we switched to bosh from websockets because we kept seeing random disconnections when using websockets.

E.g., this thread from March 2020.

I trust the disconnect issue with websockets has been resolved by now?

Thanks everyone, especially emrah and Freddie!!

1 Like

Congrats! We love success stories! :smiley:

I’m confused with so much info floating around.

What is the current state of VP9, including bridge?

Do we still need to use Jonathan’s PR and compile something or is it working in latest master/unstable out of the box?


Current state is it’s working great if you do everything right.

  1. Definitely use Jonathan’s PR – it is essential to using the layers within the VP9 stream
  2. You must use websockets, not bosh – otherwise bandwidth will not be estimated correctly
  3. You must enable simulcast on your clients – otherwise server can’t break VP9 stream into layers
  4. Not sure about non-chrome browser compatibility as we restrict users to chrome

Thanks for the great summary @Omatic

Just to be clear on what I need to do to get the great results posted in this thread.

  1. Do I still need to compile the jars as described in this thread or is there a simpler process now?

Jitsi media transform

  • Clone the jitsi-media-transform fork of @ Jonathan_Lennox (GitHub - JonathanLennox/jitsi-media-transform )
  • Checkout vp9-support branch (latest commit as of this writing is 35439ba76bf400b0235f7df968dc6f2f6e30264e )
  • Run mvn clean install -DskipTests inside the project folder (clean and -DskipTests are optional, feel free to exclude them)
  • After the process is finished, you should see a jitsi-media-transform-1.0-SNAPSHOT.jar inside the target folder of the project. Replace the existing .jar in your server with the one produced here (I suggest to keep the original one as a backup if anything goes wrong).
    Assuming you’re in the jitsi-media-transform directory and a default installation of the jitsi-videobridge project, rm /usr/share/jitsi-videobridge/lib/jitsi-media-transform-whatever.jar && cp ./target/jitsi-media-transform-1.0-SNAPSHOT.jar /usr/share/jitsi-videobridge/lib/ to remove the existing jar and copy/paste the new one in the directory.


  • Clone the jitsi-videobridge fork of @ Jonathan_Lennox (GitHub - JonathanLennox/jitsi-videobridge )

  • Checkout vp9-support branch (latest commit as of this writing is e2d34e1974754d044e42f5f57f20974cbadfe595 )

  • Run mvn clean package -DskipTests -Dassembly.skipAssembly=false inside the project folder (clean and -DskipTests are optional, feel free to exclude them)

  • After the process is finished you should see some artifacts in the jvb/target directory, inside the project’s folder.

I’m not sure if the next steps are optimal but they worked for me in multiple tries from a clean start.

  • Unzip the jitsi-videobridge-2.1-SNAPSHOT-archive.zip into a folder (e.g. unzip ./jvb/target/jitsi-videobridge-2.1-SNAPSHOT-archive.zip -d ./myFolder
  • Go to the newly created unzipped folder cd ./jvb/target/myFolder You should see a folder named jitsi-videobridge-2.1-SNAPSHOT . Inside that folder you should see a jitsi-videobridge.jar (729KB) a jvb.bat , a jvb.sh and a lib/ folder. You need to replace those files in the /usr/share/jitsi-videobridge directory (again, backup first, just for some piece of mind)

rm -rf /usr/share/jitsi-videobridge/lib /usr/share/jitsi-videobridge/jvb.sh /usr/share/jitsi-videobridge/jitsi-videobridge.jar
cp jitsi-videobridge.jar /usr/share/jitsi-videobridge/
cp -r lib /usr/share/jitsi-videobridge/
cp jvb.sh /usr/share/jitsi-videobridge/

Restart the videobridge service service jitsi-videobridge2 restart
You should not see any errors in logs tail -100 /var/log/jitsi/jvb.log


1 Like

I take it the lack of any reply to indicate that yes we still need to compile Jonathan’s branch to get VP9 working properly with bridge support.

Asking the same question but in a different way. Why hasn’t this been merged yet and when can we expect it to be merged so we don’t have to mess around with compiling jars?

Any ETA?


Hey Peter,

I think it’s because they haven’t ironed out all the bugs for other browsers, some of them don’t support VP9 bug free. IIRC Safari is one of them.

@Peter_Villeneuve @c10r0x I think it will be merged soon. Now Vp9<–>VP8 fallback is present for safari.