Hacker News Reader

Comment by krick | Hacker News Reader

I don't get what it does, exactly? This doesn't seem to be an OBS alternative (judging by the description), but… I mean, isn't it exactly the same as just running OBS directly?

View on HN

Looks like a LAN tele…er, screen sharing server/client. Presumably you could serve over the internet but it will not get the 30ms latency. Aside from the streaming (I only spent a few minutes reviewing the source) it’s a live jpeg kind of thing. I built something similar to screen share with my kids when we played Minecraft together. It was really for me because once we got in game they would take off and in 5 minutes be screaming for help 10 chunks away in some zombie skeleton infested cave at or near bedrock. Being kids, I never got good enough directions to help them in time. Anyway, it was a fun project. I used CUDA and could get 60fps per client on CAT5 and 45-ish over WiFi, dropping to 10-15fps when I walked in and out of rooms with the laptop. 60fps is 15ms, so 20 is 50fps.

>Presumably you could serve over the internet but it will not get the 30ms latency.

Indeed, you'll have to live with something like 80ms to 100ms latency over the internet and a horrifying 160 ms if you want to have things respond to keyboard and mouse inputs.

Then how does something like moonlight, parsec, or Geforce Now work? Sub-10ms latency, sometimes even sub-5 depending on time of day and network congestion.

Ever heard of the Akamai network? Netflix might be a good example. Trace routes show latency between network hops. To reduce latency you either buy better network hardware, buy better cabling, or reduce hops in n the network. Since the first two are more expensive than the third, if your service must have very fast response between server and client, move the server closer to the client. Large corporations run cache servers in multiple data centers everywhere geographically so the response time for clients is better than their competition. Why new video services struggles to compete with YouTube is in part because YouTube can afford this kind of architecture where a startup cannot. Even if it’s the best code money can buy, it will never provide the same level of experience to users as local cache servers. Kind sucks not body can compete.

GP is talking about playing remotely rendered video games, so no caching here but yes distance to server indeed.

That is only ever theoretically possible with a direct fiber connection between both nodes at <= 200 miles between.

So the answer is “there’s a data center in your city.”

It is also a player!

You can either pull the video from a WHEP source or run in a P2P mode. I wanted to demonstrate the flexibility and hackability of it all :)

Reply on news.ycombinator.com