They're just streaming a video feed of an LLC running in a terminal? Why not stream the actual text? Or fetch it piecemeal over AJAX requests? They complain that corporate networks support only HTTPS and nothing else? Do they not understand what the first T stands for?
We replaced H.264 streaming with JPEG screenshots (and it worked better)
51–60 of 332 posts
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#52Would HLS be an option? I publish my home security cameras via WebRTC, but I keep HLS as a escape for hotel/cafe WiFi situations (MediaMTX makes it easy to offer both).
Thought of the same. I have not set it up outside of hobby projects, but it should work over HTTP as it says on the box, even inside a strict network?
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#53Earlier quoted context omitted.
> Try 1Mbps and iterate from there. From the article: “Just lower the bitrate,” you say. Great idea. Now it’s 10Mbps of blocky garbage that’s still 30 seconds behind.
Rejecting it out of hand isn't actually trying it. 10Mbps is still way too high of a minimum. It's more than YouTube uses for full motion 4k. And it would not be blocky garbage, it would still look a lot better than JPEG.
1Mbps for video is rule of thumb I use. Of course that will depend on customer expectations. 500K can work, but it won’t be pretty.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#54They're just streaming a video feed of an LLC running in a terminal? Why not stream the actual text? Or fetch it piecemeal over AJAX requests? They complain that corporate networks support only HTTPS and nothing else? Do they not understand what the first T stands for?
Suppose an LLM opens a browser, or opens a corporate .exe and GUI and starts typing in there and clicking buttons.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#55Earlier quoted context omitted.
Rejecting it out of hand isn't actually trying it. 10Mbps is still way too high of a minimum. It's more than YouTube uses for full motion 4k. And it would not be blocky garbage, it would still look a lot better than JPEG.
1Mbps for video is rule of thumb I use. Of course that will depend on customer expectations. 500K can work, but it won’t be pretty.
For normal video I think that's a good rule of thumb.
For mostly-static content at 4fps you can cut a bunch more bitrate corners before it looks bad. (And 2-3 JPEGs per second won't even look good at 1Mbps.)
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#56Would HLS be an option? I publish my home security cameras via WebRTC, but I keep HLS as a escape for hotel/cafe WiFi situations (MediaMTX makes it easy to offer both).
Thought of the same. I have not set it up outside of hobby projects, but it should work over HTTP as it says on the box, even inside a strict network?
Yes, it is strictly HTTP, not even persistent connections required.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#57webp is smaller than jpeg
https://developers.google.com/speed/webp/docs/webp_study
ALSO - the blog author could simplify - you don't need any code at all at the web browser.
The tag automatically does motion jpeg streaming.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#58> 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…
>And you have to work around that, because IT dept of the corporation will never lift restrictions. Because otherwise people do dumb stuff like pasting proprietary designs or PII into deepseek
Oh, they'll do that anyway, once they find the workaround (Oh... you can paste a credit card if you put periods instead of dashes! Oh... I have to save the file and do it from my phone! Oh... I'll upload it as a .txt file and change the extension on the server!)
It's purely illusory security, that doesn't protect anything but does levy a constant performance tax on nearly every task.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#59Earlier quoted context omitted.
I think the general idea/flow of things is "numbers go up, until $bubble explodes, and we built up smaller things from the ground up, making numbers go up, bloating go up, until $bubble explodes..." and then repeat that forever. Seems to be the end result of capitalism. If you wanna kill corporate IT, you have to kill capitalism first.
I don't believe that. I don't necessarily love capitalism (though I can't say I see very many realistic better alternatives either), but if HN is full of people who could do corporate IT better (read: sanely), then the conclusion is just that corporate IT is run by morons. Maybe that's because the corporate owners like morons, but nothing about capitalism inherently makes it so.
[deleted]
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#60We did something similar in one of the places I've worked at. We sent xy coordinates and pointer events from our frontend app to our backend/3d renderer and received JPEG frames back. All of that wrapped in protobuf messages and sent via WS connection. Surpassingly it kinda worked, not "60fps worked" though obviously.