Meet Kopano (unstable version) - a few questions & problems :)
-
@jdaviescoates said in Meet Kopano (unstable version) - a few questions & problems
:all users need to have enough bandwidth for all streams or something
Yes, with a peer to peer connection all users need to connect to each other participant. Connections in Meet are limited to max 1 Mbit per participant, if a user does not have sufficient bandwidth for that the browser will automatically reduce quality down to a level where video would be deactivated completely.
Some more usage questions are answered in https://kopano.com/blog/top-10-things-to-ask-about-kopano-meet/
-
@jdaviescoates said in Meet Kopano (unstable version) - a few questions & problems
:
is a nice explanation of the pros and cons of the three main typologies used for video conference: p2p / MCU / SFUwith full p2p WebRTC apps like Kopano Meet all users need to have enough bandwidth for all streams or something
-
Also might be of interest:
An article which test a methodology to compare SFUs, and then test a few of them. Results probably do not reflect real case scenario though.
-
@jdaviescoates Seven. One left their video off. We had three reconnections but those were momentary and the reconnection initially resulted in clearer video images each time.
-
Hi all, today I introduced Kopane Meet for the first time in our (volunteers) organization for a video meeting with 1 account and 5 guests.
It was a disaster! After half an hour trying and frustration we stopped and 4 of them started a WhatsApp groupvideo (Whatsapp has a max of 4?!).
What went right?
The first 2 persons (account and 1 guest) succeeded in having audio and video.What went wrong?
All other guests could join (we could see their names) but they didn't see any video or heared audio and the first two didn't see/hear them. They could see themselves in their browser.Time to uninstall the app and hopefully Jitsi Meet will be here soon.
-
@yusf of some I know their devices/browsers:
- account: MacOS+Safari = all fine (could see/hear 2.)
- guest: MacOS+Safari = all fine (could see/hear account, BTW on same network as account)
- guest: MacOS+Safari and iPad+Safari = connected, could see himself, but no audio/video to/from others
- guest: iPad+Safari = connected, could see himself, but no audio/video to/from others
- guest: Samsung tablet with Chrome = connected, could see himself, but no audio/video to/from others
- guest: ? = connected, could see himself, but no audio/video to/from others
The WhatsApp groupvideo after half an hour strugling with four (2./3./4./5.) went perfect, so it's not a matter of bandwith I guess.
Cloudron server load or bandwith usage during the "call" was normal, so no increase in CPU resources or network (I use ZABBIX agent on the Cloudron server so can see all stats live and all history is stored).
-
off-topic: I think one lesson to learn here is that to do video conferencing properly is quite hard. You can hate on Zoom and Teams all you want but if you actually have your work depend on it (e.g. meeting with a client, like I do on a daily basis), it's quite a different story than just having fun with friends.
-
Hi @imc67,
browser versions are equally as important as the browser itself. and sadly Safari isn't the best when it comes to supporting modern standard such as PWAs and WebRTC. The general recommendation would be to use Chrome or Chromium based browsers.
@imc67 said in Meet Kopano (unstable version) - a few questions & problems
:Cloudron server load or bandwith usage during the "call" was normal
Yes, that is to be expected when using WebRTC, the majority of traffic is between individual callers. There are still some connections to the server, like for example a websocket connection to kwmserver for notifications and then of course the connection to the turn server.
-
Charming participants at the first (virtual) Cloudron meetup
-
@luckow We should do this again when @fbartels packages "Kopano Meet Boost" on Cloudron!
"Kopano Meet Boost is a server that we offer to our enterprise customers to meet this challenge. It is a Selective Forwarding Unit (SFU) that receives only one data stream from the sender and forwards it to all other participants. This drastically reduces the required computing power at the client and saves bandwidth. Thus, video meetings are also possible with 50 and more participants."
-
@oj said in Meet Kopano (unstable version) - a few questions & problems
:packages "Kopano Meet Boost" on Cloudron
thats unfortunately a bit impractical to do. kwmbridge requires a large range of udp ports so running it in a container with forwarded ports is quite inefficient (because there is also quite a memory overhead in Docker in this case).
But it should be easy to make the app configurable enough to have kwmbridge running on a dedicated host and simply hook up to kwmserver inside of the app. having (multiple) external kwmbridge endpoints is kind of the setup we are expecting anyways.
