Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.helix.ml

Post reply on HN
Print view View original

81–90 of 332 posts

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

#81

Post by j45 »

rcarmo wrote: post #10
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…

They even break server-sent events (which is still my default for most interactive apps)

There are other ways to make server-sent events work.

I try to remember many environments once likely supported Flash.

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

#82

Post by j45 »

Dylan16807 wrote: post #15

> When the network is bad, you get... fewer JPEGs. That’s it. The ones that arrive are perfect. You can have still have weird broken stallouts though. I dunno, this article has some good problem solving but the biggest and mostly untouched issue is that they set the minimum h.264 bandwidth too high. H.264 can do a lot better than JPEG with a lot less bandwidth. But if you lock it at 40Mbps of course it's flaky. Try 1…

It might be possible to buffer and queue jpegs for playback as well to help with weird broken stall outs.

Video players used to call it buffering, and resolving it was called buffering issues.

Players today can keep an eye on network quality while playing too, which is neat.

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

#83

Post by j45 »

sevensor wrote: post #78

No 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.

PNGs likely perform great, existing enterprise network filters, browser controls, etc, might not, even with how old PNGs are now.

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

#84

Post by kccqzy »

There are so many things that I would have done differently.

> We added a keyframes_only flag. We modified the video decoder to check FrameType::Idr. We set GOP to 60 (one keyframe per second at 60fps). We tested.

Why muck around with P-frames and keyframes? Just make your video 1fps.

> Now it’s 10Mbps of blocky garbage that’s still 30 seconds behind.

10 Mbps is way too much. I occasionally watch YouTube videos where someone writes code. I set my quality to 1080p to be comparable with the article and YouTube serves me the video at way less than 1Mbps. I did a quick napkin math for a random coding video and it was 0.6Mbps. It’s not blocky garbage at all.

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

#87

Post by j45 »

rcarmo wrote: post #7

This was the most entertaining thing I read all day. Kudos. I've had similar experiences in the past when trying to do remote desktop streaming for digital signage (which is not particularly demanding in bandwidth terms). Multicast streaming video was the most efficent, but annoying to decode when you dropped data. I now wonder how far I could have gone with JPEGs...

If playing with Chromecast types multicast or streaming one frame at a time manually worked pretty good.

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

#88

Post by StilesCrisis »

sevensor wrote: post #78

No 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.

PNGs are lossless so you can’t really dial up the compression. You can save space by reducing to 8-bit color (or grayscale!) but it’s basically the equivalent of raw pixels plus zlib.

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

#90

Post by michaelt »

j45 wrote: post #75
ris wrote: post #24

Earlier quoted context omitted.

Corporate IT needs to die.

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.

Post reply on HN