> And the size! A 70% quality JPEG of a 1080p desktop is like 100-150KB. A single H.264 keyframe is 200-500KB. I believe the latter can be adjusted in codec settings.
Of course. But same quality h264 keyframe will not be much smaller than JPEG.
We replaced H.264 streaming with JPEG screenshots (and it worked better)
101–110 of 332 posts
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#102> When the network is bad, you get... fewer JPEGs. That’s it. The ones that arrive are perfect.
This would make sense... if they were using UDP, but they are using TCP. All the JPEGs they send will get there eventually (unless the connection drops). JPEG does not fix your buffering and congestion control problems. What presumably happened here is the way they implemented their JPEG screenshots, they have some mechanism that minimizes the number of frames that are in-flight. This is not some inherent property of JPEG though.
> And the size! A 70% quality JPEG of a 1080p desktop is like 100-150KB. A single H.264 keyframe is 200-500KB. We’re sending LESS data per frame AND getting better reliability.
h.264 has better coding efficiency than JPEG. For a given target size, you should be able to get better quality from an h.264 IDR frame than a JPEG. There is no fixed size to an IDR frame.
Ultimately, the problem here is a lack of bandwidth estimation (apart from the sort of binary "good network"/"cafe mode" thing they ultimately implemented). To be fair, this is difficult to do and being stuck with TCP makes it a bit more difficult. Still, you can do an initial bandwidth probe and then look for increasing transmission latency as a sign that the network is congested. Back off your bitrate (and if needed reduce frame rate to maintain sufficient quality) until transmission latency starts to decrease again.
WebRTC will do this for you if you can use it, which actually suggests a different solution to this problem: use websockets for dumb corporate network firewall rules and just use WebRTC everything else
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#103Earlier quoted context omitted.
It's not corporate IT's fault, it's usually corporate leaderships fault who often cosplay leading technology and not understanding it. Wherever Tech is a first class citizen and seat at the corporate table, it can be different.
Believe me, the average Fortune 500 CEO does not know or care what “SSL MITM” is, or whether passwords should contain symbols and be changed monthly, or what the difference is between ‘VPN’ and ‘Zero Trust’. They delegate that stuff. To the corporate IT department.
But they also say "Here, this is Sarah your auditor. Answer these questions and resolve the findings." - every year
It's all CyberSecurity insurance compliance that in many cases deviates from security best practices.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#104No mention of PNGs? I don’t usually go to jpegs first for screenshots of text. Did png have worse compression? Burn more cpu? I’m sure there are good reasons, but it seems like they’ve glossed over the obvious choice here. edit: Thanks for the answers! The consensus is that PNG en/de -coding is too expensive compared to jpeg.
PNG is VERY slow compared to other formats. Not suitable for this sort of thing.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#105>A single H.264 keyframe is 200-500KB.
Hmm they must be doing something wrong, they're not usually that heavy.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#106They might want to check out what VNC has been doing since 1998– keep the client-pull model, break the framebuffer up into tiles and, when client requests an update, perform a diff against last frame sent, composite the updated tiles client-side. (This is what VNC falls back to when it doesn’t have damage-tracking from the OS compositor) This would really cut down on the bandwidth of static coding terminals where 90%…
The blog post did smell of inexperience. Glad to hear there is other approaches - is something like that open source?
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#107Earlier quoted context omitted.
Believe me, the average Fortune 500 CEO does not know or care what “SSL MITM” is, or whether passwords should contain symbols and be changed monthly, or what the difference is between ‘VPN’ and ‘Zero Trust’. They delegate that stuff. To the corporate IT department.
But they also say "Here, this is Sarah your auditor. Answer these questions and resolve the findings." - every year It's all CyberSecurity insurance compliance that in many cases deviates from security best practices.
This is 100% it- the auditor is confirming the system is configured to a set of requirements, and those requirements are rarely in lockstep with actual best practices.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#108> 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…
Request URL has a query parameter with more than 64 characters? Fuck you.
Request lives for longer than 15 sec? Fuck you.
Request POSTs some JSON? Maybe fuck you just a little bit, when we find certain strings in the payload. We won't tell you which though.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#109Earlier quoted context omitted.
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.
What's the term for the ideology that "laws are silly because people sometimes break them"?
Posting stuff into Deepseek is banned. The corporate firewall is like putting a camera in your home because you may break the law. But, yeah, arguing against cameras in homes because people find dead angles where they can hide may not be the strongest argument.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#110> 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…
At the same time, enterprise is where the revenue is.
Against all odds, you're right, that's where somehow revenue is being generated. IT idiocy notwithstanding.