We replaced H.264 streaming with JPEG screenshots (and it worked better) • Hacker News Board

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

#21

Post by refulgentis » Tue, Dec 23, 2025, 6:52 PM UTC

The LinkedIn slop tone, random bolding, miscopied Markdown tables makes me invoke: "please read the copy you worked on with AI"

smaller thing: many, many, moons ago, I did a lot of work with H.264. "A single H.264 keyframe is 200-500KB." is fantastical.

Can't prove it wrong because it will be correct given arbitrary dimensions and encoding settings, but, it's pretty hard to end up with.

Just pulled a couple 1080p's off YouTube, biggest I-frame is 150KB, median is 58KB (`ffprobe $FILE -show_frames -of compact -show_entries frame=pict_type,pkt_size | grep -i "|pict_type=I"`)

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

#22

Post by escapecharacter » Tue, Dec 23, 2025, 6:53 PM UTC

I guess this is great as long as you don't worry about audio sync?

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

#23

Post by bobmcnamara » Tue, Dec 23, 2025, 6:56 PM UTC

lostmsu wrote: post #12

If you have latency detection already why not pause H.264 frames, then when ack comes just force a key frame and resume (perhaps with adjusted target bitrate)?

Yeah, monitor the send queue length and reduce bit rate accordingly.

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

#24

Post by ris » Tue, Dec 23, 2025, 6:56 PM UTC

egorfine wrote: post #5

> The constraint that ruined everything: It has to work on enterprise networks. > You know what enterprise networks love? HTTP. HTTPS. Port 443. That’s it. That’s the list. That's not enough. Corporate networks also love to MITM their own workstations and reinterpret http traffic. So, no WebSockets and no Server-Side Events either, because their corporate firewall is a piece of software no one in the world wants and…

Corporate IT needs to die.

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

#25

Post by htrp » Tue, Dec 23, 2025, 6:57 PM UTC

escapecharacter wrote: post #22

I guess this is great as long as you don't worry about audio sync?

at least the ai agents aren't talking back to us

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

#26

Post by rzzzt » Tue, Dec 23, 2025, 6:57 PM UTC

petcat wrote: post #3

so did they reinvent mjpeg

An MPEG-1-based screen sharing experiment appeared here 10 years ago:

- https://news.ycombinator.com/item?id=9954870

- https://phoboslab.org/log/2015/07/play-gta-v-in-your-browser...

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

#27

Post by keepamovin » Tue, Dec 23, 2025, 6:58 PM UTC

This is similar to what BrowserBox does for the same reasons outlined. Glad to see the control afforded by "ye olde ways" is recognized and widely appreciated.

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

#28

Post by [deleted] » Tue, Dec 23, 2025, 6:58 PM UTC

binocarlos wrote: post #11

> I mashed F5 like a degenerate. I love the style of this blog-post, you can really tell that Luke has been deep down in the rabbit hole, encountered the Balrog and lived to tell the tale.

[deleted]

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

#29

Post by jamiesonbecker » Tue, Dec 23, 2025, 6:59 PM UTC

ddtaylor wrote: post #19

A very stupid hack that can work to "fix" this could be to buffer the h264 stream at the data center using a proxy before sending it to the real client, etc.

One of the big issues was latency.

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

#30

Post by algesten » Tue, Dec 23, 2025, 7:00 PM UTC

WebSockets over TCP is probably always going to cause problems for streaming media.

WebRTC over UDP is one choice for lossy situations. Media over Quic might be another (is the future here?), and it might be more enterprise firewall friendly since HTTP3 is over Quic.