This seems like a silly workaround at first but it’s really not. If the network is unreliable, you can’t really use normal video streaming, you need to send full screenshots. Probably still a better idea to use only I-frames than a bunch of JPEGs but whatever.
But they did make some very silly mistakes. Par for the course of an AI coding company I guess.
WTF are you doing with 40mbps. Tone it down to like 8.
If the network is reliable but slow, just reduce bitrate and resolution. Don’t use JPEGs unless packet loss is the problem.
WTF are you doing using a whole game streaming server for? It’s meant for LAN, with minimal latency. Just capture the screen and encode it, send via WebSockets. Moonlight is completely unnecessary.
Only keep the latest frames on the server. Don’t try to send them all immediately or it’ll fall behind. Wait for the client to finish receiving before sending another one. This way it won’t lag behind increasingly. This should have been extremely obvious.
H264 is so 2003, ask the client if it supports AV1 or HEVC then use that, more data for free.
Use WebTransport when available, it’s basically made for live streaming
Why are you running a screenshot tool in terminal then grabbing the jpg… Unnecessary file overhead & dependency
I probably missed some but even for an AI company this is really bad
Apparently their corporate context is inside kubernetes and prevents UDP. Personally I don’t know enough to say whether they’re just ignorant, lazy, or they have “valid” constraints.
But yeah, didn’t tmux solve this problem a few decades ago, already?
This seems like a silly workaround at first but it’s really not. If the network is unreliable, you can’t really use normal video streaming, you need to send full screenshots. Probably still a better idea to use only I-frames than a bunch of JPEGs but whatever.
But they did make some very silly mistakes. Par for the course of an AI coding company I guess.
I probably missed some but even for an AI company this is really bad
The author showed up in the hackernews comments: https://news.ycombinator.com/item?id=46367475 for the post, https://news.ycombinator.com/item?id=46372060 for the author’s comment.
Apparently their corporate context is inside kubernetes and prevents UDP. Personally I don’t know enough to say whether they’re just ignorant, lazy, or they have “valid” constraints.
But yeah, didn’t
tmuxsolve this problem a few decades ago, already?