this post was submitted on 25 Dec 2025
155 points (86.4% liked)

Programming

24065 readers
754 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] randomblock1@lemmy.world 9 points 17 hours ago (1 children)

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.

  1. WTF are you doing with 40mbps. Tone it down to like 8.
  2. If the network is reliable but slow, just reduce bitrate and resolution. Don't use JPEGs unless packet loss is the problem.
  3. 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.
  4. 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.
  5. H264 is so 2003, ask the client if it supports AV1 or HEVC then use that, more data for free.
  6. Use WebTransport when available, it's basically made for live streaming
  7. 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

[โ€“] Jayjader@jlai.lu 3 points 11 hours ago

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 tmux solve this problem a few decades ago, already?