4 ms·
The Jistsi team says the server needs roughly 5.5Mbps per Chrome user. Firefox uses a lot more bandwidth, system resources, and degrades the room capacity. Jus
by SparkyMcUnicorn 7y ago
The Jistsi team says the server needs roughly 5.5Mbps per Chrome user. Firefox uses a lot more bandwidth, system resources, and degrades the room capacity.
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.
- toohotatopic 7y agoIs there cheaper bandwidth available than Hetzner's 1.19euro +vat per TB? (Linode seems to be at 10$ / TB).
- morphle 7y agoLeaseweb can be o lot cheaper, it depends. I'm starting an ISP again, we will charge around $0,25 per TB
- capableweb 7y agoOr Hetzners dedicated hosts that have zero cost for bandwidth and unlimited traffic as well, haven't been able to find anything cheaper than that.
- iknowstuff 7y agoOVH doesn't limit it afaik.
- littlestymaar 7y ago> The Jistsi team says the server needs roughly 5.5Mbps per Chrome user. 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.
- saghul 7y agoWe use a technique called simulcast. It consists on making every participant "work a bit harder" for the good of the bunch. 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!
- applecrazy 7y agoNaive (and perhaps stupid) question here, why don't you request just the 720p feed from each participant and then rescale the streams as clients need them?
- endgame 7y agoThe server would have to downscale the received stream. That's at least one round of downscaling for each participant, possibly more if you want to send different quality versions of the same stream down to different participants.
- folmar 7y agoAnd while your device is quite capable of rescaling your stream -- even a lowest-tier smartphone will do it with no strain on its GPU -- its much more of a strain on the server to rescale 100's/1000's of stream simultaneously.
- nerpderp82 7y agoRam bandwidth is easier to manage and provision than physical bandwidth.
- jfjrjri9nn 7y agoAlmost still image is a weird way of saying “numerous still images regardless of amount of motion, that have to be stitched together in precise time sorted batches to provide a smooth experience for the viewer.” 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.