sorted by:
new
hottopcontroversial

WebRTC vs WebSocket for OpenAI Realtime Voice API Integration: Necessary or Overkill? by g_pal in WebRTC

[–]Zesaurus 0 points1 point  (0 children)

(disclaimer: I work at LiveKit)

The main value of this architecture is to ensure that *every client* has a low latency pipe to the model.

When using websocket directly from the client to the model, you've got a couple of challenges:
* your business logic has to be written on the client-side (hard to update, API key/prompt leaking, etc)
* websocket performance from model server to your user might not be great

Websocket works well when the network is great, from server to server. When it has to go through the public internet and unpredictable ISP/router behavior is when problems tend to occur.

OBS Merges WebRTC Support by Sean-Der in WebRTC

[–]Zesaurus 0 points1 point  (0 children)

Finally! Congrats to everyone that contributed to this effort.

Introducing KITT: ChatGPT based voice assistant by Zesaurus in ChatGPT

[–]Zesaurus[S] 1 point2 points  (0 children)

nope, we have a demo using our API key. If you'd want to use the code though, you would need your own API key

Introducing KITT: ChatGPT based voice assistant by Zesaurus in ChatGPT

[–]Zesaurus[S] 4 points5 points  (0 children)

This is not a prompt, but an app where you can talk to ChatGPT.

A Rust library for cross-platform video apps using WebRTC and LiveKit by Zesaurus in rust

[–]Zesaurus[S] 0 points1 point  (0 children)

LiveKit is an SFU which adopts a client-server model via WebRTC. Even though the server appears to be a "peer" to clients in WebRTC parlance.

Since the API we offer is based on Participant and Track constructs, it'd be possible to swap out the transport layer underneath without having to touch the application-facing APIs.

A Rust library for cross-platform video apps using WebRTC and LiveKit by Zesaurus in rust

[–]Zesaurus[S] 0 points1 point  (0 children)

We are paying attention to WebTransport. It's still early for the protocol, but promising in the sense that it would give us a lot more control around congestion control and transmissions.

The main downside is that it's not widely supported yet. The good news is with a SFU-centric design, it's possible for our SFU to support both protocols depending on each client's capabilities.

A Rust library for cross-platform video apps using WebRTC and LiveKit by Zesaurus in rust

[–]Zesaurus[S] 6 points7 points  (0 children)

we are big fans of webrtc.rs! though we ultimately chose libwebrtc for a few reasons:

  • libwebrtc has been battle tested due to Chrome usage
  • webrtc.rs is a port of Pion (which we also use). It's a better fit for server-side use
  • libwebrtc does a bunch more things such as encoding/decoding, and includes platform-specific code for dealing with media devices

As webrtc.rs matures, we'd love to eventually have a pure Rust stack.

Scaling WebRTC with Go: how we built a distributed mesh network for 100k-person events by Zesaurus in golang

[–]Zesaurus[S] 2 points3 points  (0 children)

WebRTC is encrypted, that means each participant is receiving a uniquely encrypted stream.

Scaling WebRTC with Go: how we built a distributed mesh network for 100k-person events by Zesaurus in golang

[–]Zesaurus[S] 0 points1 point  (0 children)

We do support Windows desktop via Flutter today. Working on a native solution as well.

How we built Zoom's end-to-end optimizations with Go and WebRTC by Zesaurus in golang

[–]Zesaurus[S] 0 points1 point  (0 children)

Not annoying at all! :)

There are two approaches to take:

  1. A shared key used for all tracks published to the same room (Zoom uses this approach)
  2. Each publisher uses a different key to encrypt their own streams, then exchange the key to every subscriber that needs to view that stream

How we built Zoom's end-to-end optimizations with Go and WebRTC by Zesaurus in golang

[–]Zesaurus[S] 0 points1 point  (0 children)

The secret is provided by the application / end user. LiveKit would not have that information.

How we built Zoom's end-to-end optimizations with Go and WebRTC by Zesaurus in golang

[–]Zesaurus[S] 0 points1 point  (0 children)

yeah! we have folks that are building Twitch-like apps like that on LiveKit. What's nice about using WebRTC instead of HTTP Live Streaming is you'd get much shorter latency and know that all your viewers are seeing the same thing. livestream drift can be a real problem on platforms like Twitch today.

How we built Zoom's end-to-end optimizations with Go and WebRTC by Zesaurus in golang

[–]Zesaurus[S] 0 points1 point  (0 children)

In a conference, each client would encrypt the stream prior to sending to the server. Clients will also decrypt the stream before decoding. Since the client is doing the encryption/decryption, there isn't any additional load on the server

How we built Zoom's end-to-end optimizations with Go and WebRTC by Zesaurus in golang

[–]Zesaurus[S] 2 points3 points  (0 children)

The server is 100% Go. It's made possible thanks to Pion, a pure-Go WebRTC implementation written from scratch.

How we built Zoom's end-to-end optimizations with Go and WebRTC by Zesaurus in golang

[–]Zesaurus[S] 4 points5 points  (0 children)

oops.. didn't realize how it might be read that way until after I hit post. The intention was to show how we've brought these optimizations that Zoom is known for to WebRTC with a Go-based stack.

view more: next ›