Hacker News Reader

I am so happy that WebRTC has so many implementations. Every developer thinks differently, it's good to have a implementation that matches your mindset.

* GStreamer’s webrtcbin (C)

See https://github.com/sipsorcery/webrtc-echoes for examples of some running against each other.

Anyone used a JVM implementation?

Sadly, SipSorcery is lagging behind as of now. We only have H.264 and VP8 support for video, data channels only have partial implementation (only reliable ordered), and the performance of data channels is far from what it could be.

But it is a great starting point for anyone working in C#.

Unfortunately, there's massive drift between WebRTC implementations. The status quo is Google's, which is used by Chrome: https://webrtc.googlesource.com/src/

And everyone else has to play catch-up.

A big source of the drift is having a common library for SDP parsing, but also necessary features like BWE, different encodings, etc.

For example, aiortc, python's WebRTC implementation, isn't quite at the level most would want. It isn't necessarily easy to tell, without clear benchmarks, which implementation is at-par with Google's.

Why do you consider it the status quo? It isn’t used in servers, embedded devices or software like OBS. Yes it’s popular because of usage in Chromium/Mobile, but I don’t believe that qualifies it as status quo.

aiortc is good enough to empower lots of businesses/projects! If anything comes up that really is a show stopper it will get addressed.

> I still don’t fully understand why more people don’t use them over something like QUIC

Dealing with NAT traversal especially with full-cone NATs is difficult and expensive - you have to maintain dedicated infrastructure of TURN servers for NAT and you have to proxy all your traffic through that, it's quite the overhead, especially since IPv4 addresses and bandwidth on AWS don't come cheap.

Here comes the inevitable HN downvote when for once I talk about something I'm professionally employed to do.

That's only if you do peer-to-peer. QUIC can't even do peer-to-peer, so I don't understand the critique.

The horrible boilerplate and complexity is why people don't use it. Getting even simple usage examples seems to be a tall order for some use cases and LLMs are hopeless in trying to help with it.

P2P connections are also often blocked by ISPs for whatever reason, making it impossible to use without a fallback TURN server which defeats the entire purpose of the thing if you wanted to do scalable multiplayer without the server infrastructure. You're left sending over the whole stream with double the latency and have to eat all the bandwidth.

> I still don’t fully understand why more people don’t use them over something like QUIC.

> the ecosystem around there is super underdeveloped compared to the ecosystem around QUIC/quinn

> There is a LOT of boilerplate involved that feels unnecessary

I think you just answered your own question and even gave the answers I would've given.

Well it’s a bit of a chicken or the egg situation right? None of those issues will get better if no one uses it.

Im excited for WebTransport for similar reasons. Being peer to peer is really cool though

I have been working on a quic/webrtc application for a while, webrtc capabilities are severely underrated since everything pairs it with TCP signaling defeating the power of webrtc

I have no knowledge of any of these but do you think webRTC might be superior to websockets for a multiplayer game at this point?

Depends!

If you want unordered/non-sequential it could help.

If you don’t care about those things could be more work for no value.