This message was deleted.

Hi Vasi! let me take a crack at these questions… 1. correct, we only charge for the greater of upstream or downstream bandwidth, never both. 2. the “client video sizing” option in the calculator is used to estimate how much bandwidth each video will take — one of LiveKit’s features is Dynamic Broadcast, which minimizes bandwidth by uploading smaller video resolutions if subscribers are only displaying smaller videos on screen 3. We designed & built the pricing calculator to be a conservative estimate — if anything, your prices will probably be a bit lower! But it’s a ballpark estimate — the biggest cause of discrepancy would be the variance in # of clients & the duration of sessions. Obviously if the actual sessions end up being longer, you’ll use more bandwidth. 4. If each user can actually only see 4 of the 10 published broadcasters, then your actual costs will probably be about half of what the calculator estimates 5. Ah, that label is not super clear, but it only applies to transcoding, which is only relevant if you’re doing Egress I hope those answers make sense! If anything is still unclear, feel free to ask more!

Thank you very much @acoustic-engineer-41666 for the in-depth explanation. I'd like to go back to numbers 2 and 4 if possible. 2.

one of LiveKit's features is Dynamic Broadcast, which minimizes bandwidth by uploading smaller video resolutions if subscribers are only displaying smaller videos on screen

Does this mean there's a way of telling the SDK "hey this is a mobile phone, so... no matter what X is broadcasting, you tell the SFU to only give you back 180p" 4 Per the example I gave, 10 broadcasters + 1000 spectators, your response doesn't make it clear what happens if "MAX NUMBER OF VISIBLE STREAMS" is set to 4. Does it mean that all spectators can receive the same 4 streams, or each one can actually choose which 4 streams to receive. Basically what I'm asking is, can each spectator tell the SFU which 4 of the 10 streams it wants to receive? ...and will the SFU deliver those streams separately or as one?

@rapid-art-42557 There are two more things worth highlighting 1. Adaptive stream: This is designed to automatically adjust the subscription. This is based on two things a. Visibility - If a video tile on the subscriber side is not visible, that stream will not be streamed from the server b. Biggest size of the video tile for a stream - this will dictate what size stream will be streamed down from the server. As a video stream can be attached to multiple video tiles on the subscriber side, the biggest tile size is used for subscription. 2. To answer which track can be seen by subscribers, SDKs provide a couple of options a. Selective subscription: Each client can choose to subscribe to whatever they need. And each client can subscribe to different publishers. b. Clients can also enable/disable track subscriptions to implement pause/resume. When a track is disabled from subscriber side, that track will not be streamed from the server. Please let us know if this covers the scenarios you are thinking about. For background effects/noise cancellation, we do not currently have the necessary hooks. Can you please elaborate a bit on your requirements there? Are you looking for those only in web app or mobile also?

@rapid-art-42557 I think @fancy-wire-61616’s response should explain #2 — you don’t actually tell the SFU “this is a mobile phone”, your client just says “I’m displaying a small video at 180p” and the SFU only sends that video. for #4, yes, if you set “MAX # OF VISIBLE STREAMS” to 4, that represents a scenario where each client can pick its own 4 streams, which can be different from the streams the other clients pick. The streams are delivered as separate RTC streams. I’m trying to imagine what app you will build based on these questions; I’m looking forward to seeing it 🙂

you can have a look at the app at sessions.us (the website) and app.sessions.us which is currently not allowing public registrations, but i'm sure we could get you an account... just say the word

Haha, yes, those are the docs. If there are any other webhook events you think would be useful, let us know! As for your other question — after some amount of time (on the order of a minute), a participant that’s not sending any data will be dropped from the room.

@acoustic-engineer-41666 please tell me the metrics used to determine when a client drops, are server sided and not (client) WebRTC-based

Well removing them from the room happens on the livekit server

I'm asking because we've dealt with this in the past, where a provider had its metrics client-based (partially) before they went with full server-sided bandwidth probing, and it turns out that client-based RTC metrics are highly unreliable