Yes, we will resume vp9 work when times permit.
Thank you. Do you have any roadmap? Do you confirm that jitsi is using VP8 and requires a bandwidth around 500 kbit/s as h.264?
Yes it is using vp8.
damencho, I’m also using Jitsi for our deployment on our own infrastructure, and had a user attempting to run a 34 person workshop in Europe. Reported high rate of disconnects and reconnects.
Once the workshop lost a number of people due to instability and landed on 24 people, the stability and video and audio quality was reported to be better.
We are running on a Last N config and checking out our servers the network and cpu utlisation didn’t go above 50% of allocated capacity, all users connected through a european JVB.
We will be investigating to see if we can do anything from our side
Ignore the above–
Analysis of our logs found no issues. Also browser analysis found that the browsers having connect issues were primarily Safari, IE and Edge.
Do you have a time frame of when it will be available?
What about JVB2.0 will/does it support VP9? If not, what is used on the new bridge? VP8, H.265 or H.264?
Appreciate your great support
There is already an issue on github about adding VP9 codec support to JVB v2.0.
thanks for the link.
So JVB2 does not support VP9 yet. But it might be in the future. Is there a time frame?
However, what codec is instead used? H.264, H.265 or VP8?
The codec is VP8. I do not know about the time frame. I hope as soon as possible since it is very important to have VP9 support.
yes, I agree! Hopfully it will be very soon.
Until then, I see in the Config a option to enable H.264. To get the best performance and lowest latency, what would you recommend to use, VP8 or H.264?
In case H.264 would be the better codec in is enabled, would there be any performance brake due to any interpreting job between the codecs at server or client side?
VP8 and H.264 belong to the same generation of codec. From the point of view of performance (bit rate and perceived quality) there is not a great differences. Moreover, VP8 is free while H.264 requires to pay royalties.
P.S. you can have a look at VP8 vs VP9 with WebRTC.
I have been testing several video conferencing systems over the last two weeks.
Jitsi-Meet using jit.si was very poor. Two people were unable to hold a steady conversation with video. The fourth and fifth people could not join.
I tried Skype, which was better but not good with only two connections. I then loaded jitsi-meet on to a dedicated server here in the UK and the performance was similar to that with jit.si.
Finally, I tried Zoom. It was impressive - eleven connections and no problems.
Zoom appears to use H.265.
Please accelerate the adoption of H.265 or VP9. It is vital both for competitive reasons and to help people during this Covid-19 pandemic.
Devices used on the calls were Linux Mint, Mac, Windows, Android, iOS. Browsers were Safari, Edge, Firefox, Chrome, etc.
If you installed your own instance, you can configure the bitrate via config.js file as described here.
Zoom is a privacy mess link1 and link2. Moreover, it supports h.264 not h.265. h.265 is very expensive in terms of royalties, I do not think that someone in open source world will use it.
I agree that the adoption of VP9 is crucial, you can vote for the issue here.
I wonder if there’s the option of going one better than VP9 and leaping straight to AV1?!
That would really put Jitsi on the map
No, since browsers do not support AV1 on WebRTC. Moreover, AV1 is CPU intensive and at the moment there is not hardware acceleration support so it is not good for mobile devices.
Oh that’s a shame. Thanks for taking the time to reply though.
I’m still evaluating the performance of jitsi. Is there any way to know about the limits of jitsi? Number of users per room? Users per server? This study is old and this project is not usable.
I found this quite recent paper of 2018 that compares: jitsi, kurento, janus and medooze. Jitsi and medooze were the best SFU in terms of number of users (490 users with 70 rooms) and RTT while medooze was the best in terms of image quality.
I actually dont think VP9 will make this a game changer, I think Zoom is not working like SFU, but rather generates 2 mixed video signals on the server and allows the client basically to downstream one of them (Gallery view or speaker view), I can be wrong though.
This way, there is only 1 stream download for every user, instead of 30, if you try to see 30 faces with Jitsi.
I think, thinking in this direction is the only way to make Jitsi a viable option for large groups/classes (30 participants) that want to see everyone on video.
The fact that you can basically stream a mixed video to Youtube is telling me that some of the needed parts are already there. It is more about thinking, how to re-structure it, so that participants stream their signal to the server, but get only one mixed signal back. And yes this will consume server performance.
Is that a direction that some folks are already thinking?
I think this is the interessing point : What is the real added value to see every video ?
I think its only psychologic (or for monitoring) because in fact , there is no value seeing each moving their head.
So i think that ChannelLastN=5 && keep the last image in the thumbnail replacing the black empty thumbnail, can be a good compromise.
That is just an idea …
May be not a game changer, but an great bandwidth improvment in this context of all the planet on internet !
just my point of view.
Good idea with keeping the last frame in thumbnail, maybe with some kidn of icon that explains that it is a photo.
Generally speaking, there is a lot of value seeing everyone in gridview as video, especially for teacher/student scenario. Teachers said, they would know if kids pay attention, or run off, especially the little once.
Yes VP9 makes a lot of sense, and will likely help here a lot as well, but getting to a similar experience as zoom, especially with low bandwidth endpoints, the general idea needs to be thought through. Having 1 or 2 streams that show all faces makes sense, having 30 streams, makes no sense, or will not be feasable, when you have 1-2 MBit download.
Well, VP9 allows to improve about 40% the number of users with the same bandwidth.
There are two solutions to conference problem: MCU and SFU. The first is better in terms of bandwidth, but much worse in term of CPU load while the second is the opposite. Zoom uses MCU approach. In general, MCU is considered the old way. With SFU you can limit the amount of streams to participants that effectively are speaking.