LiveKit Community

unfortunately, I'm not familiar with this. there are quite a bit of choices when it comes to webrtc. give our website and docs a look to see if Livekit is for you

<@U0291E7JEP3> seems to me that the biggest difference is Palava is a signaling server + Web client SDK. LiveKit is a full-blown SFU with client SDKs across all the major platforms.

Looks like the biggest competitor then is Jitsi?

Welcome <@U029G6PA4D7>! Thanks for the feedback.

1. this is actually a WebRTC limitation in general. we've fixed this in our iOS SDK by <https://github.com/livekit/webrtc-chrome/commit/6d0a36849b86773ab89ec7cb059140bb81d70eb8|patching WebRTC>
2. Try setting up the server with redis. When Redis is available, websocket connection is separated from the RTC session. WebSocket could be disconnected and reconnected without interrupting the connection.
3. it doesn't consume really any server resources to keep an idle peer connection. The current logic on the server is to wait for the publisher connection to first establish, then connect the subscriber connection. I suppose we could try to establish them in parallel. 

Thanks <@U01KZ61GV5Z> for the reply! I will try the redis configuration ! :grin:

image.png

we should add this to our .proto definitions. something like package `LiveKit`?

I would like to make a gio gui for livekit.. GIO is basically designed like flutter but is 100% golang. It can compile to Web ( as wasm), Desktop and Mobile from the same code.

Gio can also import android and apple framework libs if needed as well as webrtc lib from google.

It can also itself be compiled so that it can be imported by an Apple or Android projects.

The reason i am bringing it up is because i would like help with the due diligence from the team, and generally to see if its something that interests the team.

I used to use Flutter, but changed to GIO because you have more control, and i was already a golang developer, and so its one code base for GUI, CLI, Server, etc.

hey <@U02AF54GTCY>, GIO looks cool, and this is an ambitious undertaking. LiveKit already has a <https://github.com/livekit/server-sdk-go/|Go SDK> that supports publishing/subscribing of tracks.

the main missing piece is encoding/decoding of the video/audio data and then rendering them. that seems like the major lift in this.

The LIveKit GO SDK  is for the backend from what i read on the website.

What i am talking about is using GIO to build the frontend.    Video rendering is possible with GIO, as well as linking to the webrtc lib from chrome for the Desktop and Mobile versions.

I am happy to help out with this work, as i use golang and gio for almost all project and i also work with the pion devs and CloudWebrtc ( wei wei) in china.

yup, it's designed to be a server SDK, since that's where people use Go. However, it has capabilities for sending/receiving tracks just like the other client SDKs.

Here is my github: <https://github.com/gedw99>

Examples. There are many now as many devs have started using GIO for productions apps as well as companies.

Chat example: <https://github.com/gioverse/chat>

I'm sure one could make an electron app with the js or react libs. It's essentially the same as web from that point. Not sure if there's a way to access native webrtc bindings that way, might be a cool addition if it's different from the typical browser implementation.

Some people just want to have a Desktop client!

yeah I think most people do electron today, which lets you use all of the web technologies for UI. Flutter looks promising too, thanks to the flutter-webrtc project.

the key piece is the webrtc bridge. It's relatively straight forward to build a livekit client as long as the platform has the right bindings to Chrome's webrtc libs

Flutter would be fun to do as am experimental

we are working a on flutter SDK, so it might be doable then :slightly_smiling_face:

I'm looking forward to it also :star-struck: but as far as I know there is no public repo yet :smiling_face_with_tear:. (I asked <@U01KZ61GV5Z> before) (I could continue with my _*sloppy version*_ but re-inventing what the <https://github.com/orgs/livekit/people|great team> is working on doesn't make much sense :joy:...)

hah, it's almost ready to for folks to check out. can you guys DM me your GH handle? I'd love to get some feedback from folks with experience in Flutter to make sure we are getting the APIs right

<@U029T1GQBPY> <@U0291LHSLQL> plz DM me your github handles. will add you

Hey Daniel, it’s two peer connections total. One publisher connection and one subscriber connection, where other participant tracks are received.

Thanks for the answer. Ok, that sounds cool. But does it not mean that we’re dealing with MCU instead of the SFU?

no, we are still sending distinct tracks over the same connection.  an MCU would be mixing all fo them together and doing some form of media processing

Ah, I see, that’s cool! Do you know if there are any docs on how it works internally in such case? What interests me is how the sdp offer from the server for the subscription will look like when the subscription contains tracks from multiple peers in the room and also if the sdp offer is going to be sent again once a new user enters the room (if so, this would probably mean a short interruption of the video/audio stream?). Sorry if the question is dumb :slightly_smiling_face:

not at all :slightly_smiling_face: this is pretty deep in the webrtc stack, but no, it would not pause when you renegotiate to add more tracks. existing streams that have been running do not get interrupted

you can add/remove tracks to the connection anytime without affecting unchanged tracks

But isn’t the new offer required from the server when the new client comes in? What I was curious about is that the sdp offer oftentimes contains the ICE candidates (these won’t be required when the new client connects once the peer connection is established once), but also the description of available tracks, their quality etc and so I had this scenario in mind that several new clients may have a different configuration for their tracks and so the other side will have to know about this somehow.

I had some experience with Janus in the past (their implementation is not as elegant as LiveKit IMHO;)), but in their case the problem with different qualities was somewhat solved by different sdp offers, i.e. there were multiple subscription sessions for every user.

`but also the description of available tracks, their quality etc` - it actually describes their type and codec (i.e. video/h264), but no information about the quality (resolution/bitrate) of the tracks.

the problem you are talking about can be resolved by using Simulcast. Simulcast allows each client to publish multiple versions of the same video at different resolutions/quality, and it allows the SFU to choose the right version to forward to each participant.

LiveKit already does this today, I'm writing a blog post about this and will share here.

Alright, sounds amazing! Thanks for the clarification :thumbsup:

we did look at RN, the challenge is react-native-webrtc does not support Unified plan / transceiver API. When they do, it should be fairly straight forward to make our JS client compatible with it.

here's <https://github.com/react-native-webrtc/react-native-webrtc/pull/773|a PR> that attempted to add this support, which has been abandoned. I believe the maintainers are working on their own take

Screenshot_20210807-024406.jpg

To be fair, <@U02AGNYH2UA> in here, and all our email addresses are visible to each other :wink:

Might be worth toggling off email visibility

Yeh, most these market research firms are pretty sketchy.

yeah. going to turn off email visibility. that's a good call. sorry about that guys. I'm going to let Jeff know to stop spamming everyone

I got this e-mail too and just a couple minutes ago I’ve received another follow-up e-mail from him…

There's an opt out button on the emails, but I did also send a grumpy reply and hit the "report spam" button.

feel free to ignore this. I've turned off email visibility in Slack and have notified Jeff to stop this behavior

Thanks for sharing this! Curious, which cert authority is issuing the cert?

Let's encrypt. I'm using a nodejs script on heroku to update the certificate :grinning:

Hey folks, for those that are looking for webhooks support, it has arrived in <https://github.com/livekit/livekit-server/releases/tag/v0.12.0|v0.12.0>! Accompanying docs <https://docs.livekit.io/guides/webhooks/|here>.

how does the app work? with Tiktok, it's playing back static video clips that's uploaded by users.

livekit doesn't really work without the client SDKs, since you'll need it to receive/playback webrtc tracks

I wanted to have a feed like venmo that's worldwide when a user posts a short clip 15 - 45 secs video or audio clip. One feature of the app is to be able to attend a live personal concert or Q&amp;A with a musician/artist this is the feature that i'll be using live kit on.

awesome, I think you would want to use the client SDK within the app. that'll let you pull tracks from the musician and render them.

Hi Milan, yes you can! permissions can be updated by calling the server api <https://docs.livekit.io/guides/server-api#updateparticipant|UpdateParticipant>

this looks awesome! I'll link to this from the main project

First of all, thanks for the Flutter SDK :clap::skin-tone-2:
I did experience a few glitches with the depending package flutter_webrtc, for example audio will not play for Web. Setting audio stream to a VideoRenderer made it work.

thanks for the report Hiroshi, this makes sense due to the difference of how audio is handled on web vs native. we'll look into it

hey Jason, yeah, the mobile example app doesn't support screen share yet.

Screenshot 2021-08-26 at 9.55.22 PM.png

This is one of the know issues of flutter_webrtc (WEB) I've encountered. I had to modify some code (you need to set the audio stream to a VideoRenderer), another bug is that disposing a VideoRenderer will cause *all* audio to stop so if multi participants this will be an issue. Both bugs were not hard to fix you need to know where to modify. I might publish a fork of flutter_webrtc with fixes if anybody is interested. (flutter_webrtc is very buggy especially for WEB)

<@U029G6PA4D7> that'd be great if you can fork and create PRs for flutter_webrtc. so we can continue to get improvements from the main repo.

I'm handling the audio track difference within the livekit sdk, due to the way we use it. we'll automatically use an audio renderer for it

<@U02CAANFV25> This will take a few weeks at least since it needs to accepted by flutter_webrtc, but I will let you know :clap::skin-tone-2:

lmk if you have trouble getting their attention.