It's a fantastic open source solution. Can be self hosted.
It is to note that traffic does go through the server, hence need decent bandwidth. the server afaik does have the keys to decrypt traffic
It is to note that traffic does go through the server, hence need decent bandwidth. the server afaik does have the keys to decrypt traffic
Just something to keep in mind, and after some testing I saw the same results.
My AWS bill was projected to be over $1k/month, so I put it on Linode where it'll cost between $100-200/month. Just about any decent VPS provider would be good options compared to AWS due to bandwidth.
I'm starting an ISP again, we will charge around $0,25 per TB
That sounds like a lot! I wonder why an almost still image can use that much bandwidth, I guess it has to do with the low-latency requirement but I would love more details on that.
That is, every participant sends 3 separate video resolutions to the server: 720p, 480p and 180p (this may change due to bandwidth constraints). Then the server will only forward the approopriate layer to each other participant. So, if you are only seeing me in a thumbnail it will only forward the 180p layer. If I become the active speaker (or you choose to pin me to the large view) the server will immediately switch to forwarding the 720p layer.
In addtion, we use SVC with temporal layers, so thumbnails may be given at just 15fps or even less.
We do have a trick up our sleeve (but IIRC it haad to be disabled for the time being) which involves disabling the ssimulcast layers that nobody is requesting. That is, if nobody iss seeing me in the large view, why send the 720p layer at all?
Hope that helps!
What's the state of this in jitsi? I can only find limited info about SVC [2] and that is only on temporal layer. How much bandwidth does it even save in practice - maybe it's not worth the complexity trade-off?
[1] http://webrtchacks.staging.wpengine.com/chrome-vp9-svc/
[2] https://github.com/jitsi/jitsi-videobridge/blob/master/doc/s...
If I take a 720p video of a webcam and encode it to be delivered as progressive live streaming, the resulting stream is going to be less than one Mbps : because the image doesn't move much, I don't need many key-frame, one every 4 seconds is more than enough, and I've seen streams with no more than one every 30s (live streaming of harbours' CCTV cameras, don't ask me why). But of course it won't be realtime either, and you're gonna have a few seconds of latency. While this is OK for live streaming, it is certainly not for a video chat room.
What I'd like to know is why the latency requirement reduces that much the encoding efficiency. Do you have an idea ?
Thinking about the use case it’s obvious this isn’t a simple calendar app amount of data.
I bet if you create some images in various resolutions these services support and what looks good to your eye, then fill folders with sequences of them, you’ll see why it’s a lot of bandwidth.
Better to over communicate and let the client deal with the organization as it’s designed to and not let some network admin nickle and dime over bits.
Financial economy doesn’t really say much about the literal economy of building all these toxic gadgets.
Given the big picture, not sure why such a trivial concern as bandwidths ephemeral money cost would foster such strong curiosity.
Even then, code is in a repo. Go learn.
Traffic only goes through the server for users behind NAT, triggering the TURN path.
Source: https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-i...
That said, it is worth pointing out that this thread is specifically about videobridge (i.e. scaling beyond a full mesh).
Video shenanigans can be a dark art, but not that magical ;-)