December 23, 2025
When in doubt, screenshot it out
We replaced H.264 streaming with JPEG screenshots (and it worked better)
From silky video to rapid-fire screenshots—because café Wi‑Fi said nope
TLDR: A startup ditched fancy video streaming for rapid JPEG screenshots because corporate firewalls and bad Wi‑Fi made real-time video unusable. Commenters split between calling it a clever, reliable throwback and mocking it as “reinventing MJPEG,” with added warnings that corporate networks often break anything fancier than plain HTTPS.
Engineers built a shiny, hardware-accelerated video stream so people could watch AI bots write code in real time—then nuked it and started blasting JPEG screenshots instead. Why? Corporate firewalls and sketchy coffee-shop Wi‑Fi turned their sleek setup into a 45‑second delay parade. The devs tried fancy fixes, but when network traffic crawled, their video piled up like airport luggage. So they did the unthinkable: go old-school. And the comments? Absolute mayhem.
One camp is howling with laughter: “so did they reinvent mjpeg,” snarks one user, calling it the tech version of discovering vinyl records. Another crowd says pragmatism wins—if your boss’s firewall only speaks HTTPS on port 443, you ship whatever works. Veterans rolled in with war stories from 3G days and declared this a glorious 1994 fallback moment. Meanwhile, the tinfoil-hat-but-maybe-true crowd warns that big-company networks spy on and rewrite traffic, so even WebSockets can get zapped. And a classic hot take landed: if the “screen share is a robot typing,” why not send text instead of graphics? Cue replies explaining that text alone doesn’t show cursors, animations, or UI states—aka the “you had to be there” of screen sharing. Verdict from the peanut gallery: it’s messy, it’s funny, and it works—which in enterprise land is the only metric that matters.
Key Points
- •Enterprise network constraints (HTTPS on port 443, UDP blocked) made WebRTC unworkable for Helix’s real-time streaming needs.
- •The team built an H.264-over-WebSockets pipeline using GStreamer + VA-API for encoding and WebCodecs for browser decoding, achieving 60fps at ~40 Mbps with sub-100 ms latency in ideal conditions.
- •Under congested networks, TCP buffering caused increasing lag, making the stream tens of seconds behind despite bitrate reductions.
- •A keyframes-only (IDR) fallback with GOP=60 failed in practice, delivering only a single frame due to issues in their Wolf/Moonlight-based protocol layer.
- •They ultimately replaced the video stream with JPEG screenshots sent over HTTPS (e.g., grim | curl), which proved more robust on sketchy Wi‑Fi.