Live data from Hacker News

We replaced H.264 streaming with JPEG screenshots (and it worked better)

blog.helix.ml

291–300 of 332 posts

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#291

I'm confused, do people actually watch their agents code like it was a screen share? Why does the AI even mess with that, just send a diff over text? Is it getting a keyboard next? This is the definition of over-engineering. I don't usually criticize ideas but this is so stupid my head hurts.

And working in this setup at all sounds horrible. Who wants that?

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#292

You spent 3 months on this hacked together garbage when you probably could’ve just configured a pre-existing solution off the shelf with like 10 minutes of reading and understanding documentation. This blog post reeks of “you can just do things” type of engineering. This is the quality of engineering I would expect from “TPOT” (that part of Twitter) where people talk about working 12 hour days. It’s cause they’re wor…

Thanks! Exactly what I think about their work and their idea to people watching AI agents to code.

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#293

what about av1?

What's about configuring the codec correctly? Using mjpeg? Using VNC? Throwing all this shit into the trashcan and get just diff's in utf-8 from the coding agent?

Or maybe self-write the code to not create this hell of bullshit code that lead to the issues the article writes about?

Which you a Merry Christmas! :D

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#294

Earlier quoted context omitted.

Why would you do that? Nearly-static content is where you want even fewer keyframes than usual. In a situation like this you need them when the connection is interrupted and you reset things, and not much of anywhere else.

1 FPS with GOP 60 might just simply not play in some players.

You wouldn’t use 1fps in conjunction with GOP 60. The original article wanted exactly one key frame every 60 frames and the server drops all frames other than keyframes. I was pointing out that this is a roundabout way of achieving 1 fps.

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#295

I remember 12 years ago, while the Flash vs Html war was still raging on (pre-html5), I created a framework to create web video playback using CSS and JPEGs. It would expect a set of big JPEGs, each containing the frames of the video in a grid (a "reel"), and play it by changing the css background position (and swap out the background with the next jpeg once a "reel" was complete). It worked really well, and I also c…

I built a similar solution around the same time for semi-transparent PNG sprite animations. I remember the biggest issue was working around the GPU texture limitations on the early iPads which were exposed by mobile Safari.

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#296

"By the time you see a bug, the AI has already committed it to main" Beside of that the Author has no plan at all about encoding, mjpeg, vnc,.... Really, THIS is the product that they sell?! This sounds like a horrible work. Observing a coding agent that does my job, but faster and crappier than me and stopping it when it does totally bullshit to prevent it from commiting to main?

I can totally see some middle managers swallowing "You get used to it, I don't even see the code, All I see is blond, brunette, redhead" sales pitch.

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#297
I appreciate the honesty in this article, hacking a solution together that works is ultimately what counts. Having said that, why H264?

If I understand correctly, the clients of the video stream are web browsers and perhaps mobile devices, and the servers are Helix's. Would SVT-AV1 with low-latency mode not be an option?

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#298
post #251

Earlier quoted context omitted.

>Don’t assume something you cannot prove. Well it's an inherently unprovable accusation, so assumption will have to do. It reeks of LLM-ese in certain word choices, phrases, and structure, though. I thought it was quite clear. >It was great writing Err... no accounting for taste, I suppose.

Just saying but LLM-ese as the common dominator of how people wrote, it is likely the writing style of a lot of people

How many people do you know that use em dashes —- none.

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#299

40mbps for video of an LLM typing text didn't immediately fire off alarm bells in anyone's head that their approach was horribly wrong? That's an insane amount of bandwidth for what they're trying to do.

If all you know is vibe coding and the llm didn’t tell you 40mbs is too much how would you know?

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#300
post #280

Wait what? 40Mbps for a remote desktop? Event 10Mbps is insane. I remember deploying sunrays over dialup and the image wasn't that bad, yes it was low resolution and I think it was UDP, but the desktop was usable with a surprisingly low latency. To monitor an IA you can lower the bit depth considerably and not lose that much details on what is happening. If you control the web rendered, disable text anti aliasing, an…

I’ll say it.

Young engineers are bad.

Post reply on HN